Hallo alle zusammen, kurz zu mir, ich bin Informatik Student, habe einfache Kenntnisse, eben das was man in der ersten Semestern so lernt. Ich Interessiere mich für die Embedded Programmierung und bin auf der Suche nach einer Möglichkeit mir in diesem Bereich Grundkenntnisse anzueignen. Die Überlegung war das Olimex das SAM7-P256 mit Olimex ARM-USB-OCD-H JTAG Debug Interface anzuschaffen (zusammen ca. 100€). Wäre solch ein Board für einen Anfänger passend oder gibt es evtl. bessere ? Erste Lernziele sind Interruptsteuerung, Speicherverwaltung und I/O. Denkbares erstes Projekt: Ansteuerung von einem LED Cube der verschiedene Muster ausgeben kann und diese über Schalter verändert. Wie gesagt, über eine Empfehlung für bestimmte Hardware / Adapter würde ich mich sehr freuen, vielleicht hat der ein oder andere auch einen guten Rat. Vielen Dank im Voraus !
DonKanaille schrieb: > Olimex das SAM7-P256 mit Olimex ARM-USB-OCD-H JTAG Habe früher selbst Olimex genutzt aber inzwischen spricht folgendes dagegen: Die Hersteller bieten inzwischen ihre Boards genauso günstig und ein professioneller Debugger ist schon dabei. Daher bietet Olimex auch keine neuen uC Boards mehr an. Auf dem genannten SAM7-P256 ist ein ARM7 der inzwischen durch Cortex M3/M4 abgelöst wurde. Ich würde ein Cortex M3/M4 Board mit professionellem J-Link Debugger empfehlen z.B. http://www.embeddedartists.com/products/lpcxpresso/lpc1549_xpr.php Oder mit CMSIS-DAP Debugger (Open-Source) http://www.embeddedartists.com/products/lpcxpresso/lpc1769_cmsis_xpr.php DonKanaille schrieb: > Ansteuerung von einem LED Cube Für sowas kleines wäre eventuell auch ein Cortex M0 zu empfehlen, den es dann auch als DIP fürs Steckbrett gibt: http://www.embeddedartists.com/products/lpcxpresso/lpc812_max.php Noch was ganz anderes: auch das Raspberry Pi 2 mit Cortex A7 kann ohne Betriebssystem programmiert und als günstiger uC verwendet werden: http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal-programming-in-cpt1/
Hast Du denn schon einen Kurs in C erfolgreich abgeschlossen? Das würde ich Dir als erstes empfehlen. Und eine gewisse Erfahrung in der Implementierung von Programmen auf PCs. Insbesondere ein paar Basisalgorithmen. Sortieren, Suchen, ein paar komplexere Berechnungen. Da gibt es genügend Fallstricke die nicht mit uCs zu tun haben. Letztlich ist der konkrete Mikrocontroller eigentlich egal. Das wirst Du an den Flamewars sehen, die hier um die "richtige" Wahl kreisen. Vielleicht ist der AVR oder PIC für den Anfang etwas einfacher, da die Peripherie weniger komplex ist. Das ist alles. Kauf Dir so etwas oder halt was, was Dir interessant erscheint.
Tja.... der alte Flamewar zwischen den Anhängern der 8bit-Mikrokontroller. Lohnt es sich überhaupt noch die Einarbeitung in die 8bit Tricksereien? Oder besser gleich mit C++ auf Cortex M7 anfangen?
> 8bit Tricksereien?
Wie bitte? Was ist das?
Stefan U. schrieb: >> 8bit Tricksereien? > > Wie bitte? Was ist das? Da 8bit-MCUs nur 25% des magischen Rauches von 32bit-MCUs beinhalten, andererseits aber dieselben Berechnungen machen sollen, muß man die übrigen 75% des magischen Rauches in Software emulieren, und das sind dann die 8bit-Tricksereien.
Schau doch mal was die Chinesen an boards haben, da kommste vermutlich etwas günstiger mit weg.
atmega328-board + programmer für deutlich unter 10€ ist für jeden Anfänger völlig ausreichend. Drunter -atmega8- sollte man nicht weil hoffnungslos veraltet. Drüber -ARM- bringt am Anfang keinen zusätzlichen Erkenntnisgewinn. Einfachste Programmierumgebung ist winAVR.
Das Discovery Board von ST hat einen Debugger schon dabei. http://www.exp-tech.de/mainboards/arm?p=2 Als Entwicklungsumgebung eignet sich CooCox und GCC. Die Olimex Bards sind auch nicht schlecht, man braucht aber zusätzlich einen Debugger der mit ca 60 Euro dann für heutige Verhältnisse recht teuer ist. Wichtige ist auch welche Software, Betriebssystem unterstützen das Board bereits.
http://www.cypress.com/documentation/development-kitsboards/psoc-4-cy8ckit-049-4xxx-prototyping-kits $4 Cortex M0 sollte zum Reinschnuppern reichen. Hat allerdings keinen Debugger...
> Da 8bit-MCUs ... muß man die übrigen 75% des magischen Rauches in > Software emulieren, und das sind dann die 8bit-Tricksereien. Das ist doch quatsch. Ich benötige nur selten 32bit Operationen. Und die kann ein 8bit Mikrocontroller genau so gut ausführen, wie ein 32bitter - nur etwas langsamer. Außerdem empfinde ich das Zerlegen von Operationen in Teilschritte keinesfalls als Trickserei. Auch 32 bit Geräte zerlegen viele Operationen in kleinere. Das ist ganz normale Computertechnik. Wenn wir Menschen schon in der Grundschule mit 32bit Binärzahlen rechnen würden und unser Zeichensatz 32bit Unicode wären, dann könnte ich das vielleicht noch nachvollziehen. Ich bin allerdings mit Computern groß geworden, die ca 1 Millionen 8bit Operationen pro Sekunde ausführen konnten. Verglichen damit ist ein Atmega168 schon ratten-schnell - selbst bei 32bit Operationen. Am Beispiel Intel habe ich gelernt, dass man mehr Mhz und cleverem Cache mehr anfangen kann, mit mehr Busbreite. Der Wechsel von 32bit auf 64bit hat im PC Bereich ungefähr gar nichts gebracht. Eine Verdoppelung der Taktfrequenz mit entsprechend schnellem Speicher war hingegen schon spürbar. Für mich ist der einzig spürbare Vorteil von 64bit Linux, dass die Programme mehr Speicher nutzen können. Aber das ist eine ganz andere Baustelle, da geht es primär um die Größe der Adresssen, nicht um die Breite der Rechenregister.
Ich hatte irgendwann das Problem, dass meine Logik-Schaltungen zuviele 74HCxxx ICs benötigten und habe mich daher an AVR herangewagt. Hab mir ein Entwicklungsboard um 50€ gekauft und mit dem AVRStudio begonnen. Nach einer Stunde wusste ich, dass die 50€ für das Enwicklungsboard rausgeschmissenes Geld waren...ich hätte mir gleich einen ATxx um 2€ kaufen sollen und direkt programmieren ... so einfach war alles. Wer mit 32Bit µCs anfängt, hat halt schon einen ganz anderen Befehlssatz und Funktionsumfang vor sich. Wenn man aufwändige Berechnungen machen will, dann ist das schon gut, aber für Logik Schaltungen nicht notwendig.
Da der Sinn hinter C ja ist die Hardware noch ein Stück weiter zu extrahieren, ist es eigentlich egal welche Hardware Du verwendest. Ich würde Dir da aber was simples empfehlen bei dem Du einfach Deinen Port einschaltest und Du nicht erst mal deinen Takt zum Port hin leiten musst bis das Teil was macht. Um C zu lernen musst Du aber erst mal ansatzweise Assembler können, sonst wirst Du viele Sachen nicht verstehen. C ist eine Sprache die zum Verständnis Assembler voraussetzt.
Es ist sicherlich hilfreich, wenn man Assemlber kann bzw. kennt bevor man mit C beginnt. Es ist aber nicht zwingend notwendig! Mit Assembler-Kenntnissen ist es leichter zu verstehen wie die HW arbeitet und somit geht man bei der C Programmierung etwas anders vor als wenn man auf einem PC in C programmiert.
Christian B. schrieb: > Um C zu lernen musst Du aber erst mal ansatzweise Assembler können Dem ist keineswegs so. Aber wenn Interesse an Assembler besteht spricht nichts gegen einen Einstieg mit ARM bei dem 90% der Programme mit 25 Befehlen auskommen, das kann man problemlos lernen z.B. http://www.peter-cockerell.net/aalp/html/frames.html Hosenmatz schrieb: > AVR oder PIC für den Anfang Es spricht gar nichts gegen 32-Bit ARM für den Anfang, aber wenn doch 8-Bit dann wohl eher ein Industrie-Standard 8051 Board mit professionellem J-Link Debugger z.B. http://de.rs-online.com/web/p/entwicklungskits-prozessor-mikrocontroller/9140107/?sra=pmpn
Lass den Assembler sein. Vor 25 Jahren habe ich mein Geld damit verdient. Doch heute brauche ich den gar nicht mehr. Geht auch alles mit C++, selbst Interrupt Routinen. Mein Projekt ist portabel, das läuft auf ARM und Mips Prozessoren. Das würde mit Assembler gar nicht gehen. Ich weiss nicht mal mehr, wie die Assembler-Befehle auf dem Mips-Prozessor lauten. Meine Empfehlung (mal was anderes): Ein NXP Xpresso Board (ARM M0). Kann einfach über USB programmiert und auch debugt wergen. Die IDE in Eclipse geht gut. Die Beispiele sind ordentlich. Ein I2C-Sensor ging innerhalb von 2 Stunden. Und das Board kostet auch nur 20 Euro.
Also ASM brauchst du um die C Umgebung zu initialisieren oder um Multitasking zu realisieren. Ich gehe davon aus das du als Informatik Student etwas über RISC-, CISC-CPUs, Programmierung in C, C++, SML, Java usw. weist. Am einfachsten ist ein Arduino, da hast du in 1 Minute eine Led geschaltet, wenn du allerdings dann was sinnvolles machen willst musst dich durch den ganzen Arduino Scheiß arbeiten. Wenn du in ASM programmieren willst nimm einen AVR. Wenn du aber auch ein Multitasking System wie FreeRTOS, ChibiOS oder ähnliche und eventuell auch einen LwIP Stack brauchst, dann nimm C und eigentlich sollte C durch C++ abgelöst werden. Vorhandene Software ist aber meistens in C geschrieben. Wenn du viel machen willst und viel selber machen willst(kein Linux) dann nimm eine Cortex M4, viel RAM und Flash, besser mehr als zu wenig.
Erstmal vielen Dank für die ganzen Beiträge, das hat mir sehr geholfen ! Am meisten Interesse habe ich derzeit an folgendem Board/Bundle: http://www.embeddedartists.com/products/boards/lpc4088_exp_bb_bundle.php Da das LPC4088 jedoch etwas außerhalb meines Budgets liegt tendiere ich aktuell zu dem LPC1549 (auch Cortex-M4) wie es empfohlen wurde: http://www.embeddedartists.com/products/lpcxpresso/lpc1549_xpr.php Ich werde mich noch weiter Informieren und in den kommenden Tagen entscheiden. Da Fragen zu meinem aktuellen Kenntnisstand aufgekommen sind, kurze Infos. Derzeit bin ich auf dem Stand vom 3. Semester und habe unter anderem Vorlesung absolviert in denen die Basics vermittelt wurden, welche auf die Embedded Programmierung abzielen... Programmieren (C,C++,Assembler), Algorithmen, Datenstrukturen, Mikroprozessorsysteme, Rechnerarchitektur, Betriebssysteme, usw. Nochmals danke an alle, echt super nett von euch !
Wenn Du mit NXP anfangen willst, solltest Du Dir vielleicht auch mal: http://www.ebay.com/itm/182181945201 ansehen. Ein passendes Display (3.5") gibt/gab es dort auch. Der 1768 ist der Superset-M3 von NXP. D.h. alles was an Peripheriemodulen innerhalb der Serie vorhanden ist, ist auch beim 1768 dabei. Sehr zu empfehlen dazu waere ein J-Link. Enweder als Edu-Version oder in schwarz vom Chinesen :-).
Ein STM32F0 Discovery (Cortex-M0) gibt es zur Zeit für 5€ + 2,90€ Versand bei eBay: http://m.ebay.de/itm/Entwicklungsboard-STMicroelectronics-STM32F0308-Falue-line-Discovery-1-Stuck-/311646653104?hash=item488f968ab0%3Ag%3A7NEAAOSw-KFXdQSJ&_trkparms=pageci%253Abf1040fd-6455-11e6-bbad-005056a01e3b%257Cparentrq%253A97a55d171560a78546269786fff16835%257Ciid%253A4 Vom gleichen Versender gibts das F429 Discovery (Cortex-M4) mit LCD und SDRAM für 15€. Beide haben nen ST-Link Debugger on board. Für das Geld kann man eigentlich nicht viel falsch machen.
PittyJ schrieb: > Lass den Assembler sein. Der Sinn hinter der Empfehlung mit Assembler zu arbeiten ist nicht, um damit später Geld zu verdienen, sondern als Lehrmethode. Ohne Assembler wirst Du C und C++ nicht verstehen und auf ewig verdammt sein, nicht zu wissen, was Du eigentlich machst. Assembler lehrt besonders eine Sache, nämlich seine Probleme möglichst einfach zu lösen. Sprich Du überlegst Du zuerst was Du machst, und findest dann die einfachste Lösung. Das ist eine Fähigkeit die scheinbar nur wenige Leute haben. Das sind dann auch die Leute die in Firmen ihre Projekte rechtzeitig und in hoher Qualität ausführen.
Ich habe ein mehr oder minder komplexes Projekt ohne am Kenntnisse geschrieben und es tut was es soll. Es geht also auch ohne. Hätte ich die zeit, würde ich aber sehr gerne mal in asm reinschauen. Genau aus dem Grund den Christian Berger nennt.
:
Bearbeitet durch User
Wenn du in ASM mal reinschauen willst dann lass deinen c-code einfach mal in ASM source übersetzen. Du wirst dann sehr schnell drauf kommen das du nicht in ASM programmieren willst. ASM hilft dir dabei zu verstehen wie die CPU funktioniert. Wenn du C programmierst ist es schon gut wenn du verstehst wie die CPU funktioniert. Du solltest schon wissen ob eine Variable am Stack oder im RAM ist. Was ein Register ist. Was eine Adresse und der Inhalt ist. Es ist aber nicht notwendig die ganzen AMS Befehle zu kennen. Um gute C++ Programme zu schreiben brauchst du kein ASM sondern musst wissen wie man objektorientiert programmiert und keinen Spaghetti Code produziert.
Christian B. schrieb: > Um C zu lernen musst Du aber erst mal ansatzweise Assembler können Ich bin da anderer meinung. Assembler zu lernen ist nicht notwendig, um C zu lernen, eher Kontraproduktiv. Die Idee bei C code zu wissen was der Compiler daraus für assembler macht ist zum scheitern verurteilt, weil nicht nur jeder Compiler etwas anderes macht, der Compiler kann auch ganz andere Implementationen als der C-Code verwenden. z.B. eine sprung Tabelle in asm aus vielen if abfragen in c, oder separate Prüfungen und Jumps in asm wo man eine Sprungtabelle mittels switch in c wollte. Es kann sinn machen ASM und C gemeinsam zu verwenden, aber dann braucht man nur die ABI und etwas ASM zu kennen. Wenn man ASM Verwendet macht das die Dinge auch nicht einfacher, man muss selbst Register sichern, hat Prozessorspezifische Befehle mit allerhand Seiteneffekten, die man kennen und Ausnutzen muss, nur um ne einfache if abfrage mit etwas boolscher logik in asm nachzubauen, z.B. durch nuzung des carry flags und nem entschprechenden jmp Befehl. Solche Dinge eben, an die man in C nicht denken sollte. Es ist zwar sicher so, dass ASM gut ist um das Prozedurale denken zu üben, also z.B. um X zu bekommen, brauche ich b und muss dannach über schritt c d berechnen, um über d X zu bestimmen, etc. Allerdings ist diese Schritt für Schritt denkweise auch in reinem C wie jeder Anfännger anfängt. Die Schwierigkeiten starten erst, wenn die Anfänger lernen müssen, den Code zu Strukturieren, Konzepte wie OOP, Paradigmen wie Statemachines, oder Datenstrukturen wie Verlinkte Listen und Stacks zu lernen. Ich denke beste die Vorgehensweise beim Lernen von Programmiersprachen wie C ist wiefolgt: 1) Allgemeine Programmflusskontrollstrukturen für Prozedurale sprachen lernen, wie Bedingungen (if, else), Schleifen (while, for), Funktionsaufrufe 2) Variablen + Operator Präzedenzen, eigene Funktionen, Parameter und Storage duration, sowie Variable Scope (sichtbarkeit) 3) Pointerarithmetik 4) Aufteilen von Code in möglichst viele Funktionen, wobei möglichst jede Funktion eine klare Aufgabe erfüllt, und einen eindeutigen selbstbeschreibenden nicht zusammengekürzten Namen hat, z.B. "list_addItem" statt "lait" (gillt auch für Variablennamen, ausser bei i,j,k,l). 5) Grupieren von zusammengehörenden Daten in Structs 6) Unterteilen von Programmteile im Module/Compilationsunits, die Möglichst unabhängig voneinander sind. Evtl. Schichtenarchitekturen studieren. Rekursive Abhändigkeiten vermeiden. 7) Lernen algemeiner Datenstrukturen und Algorithmen, wie diverse Listen, Sortieralgorithmen, etc. 8) Betrachten anderer Konzepte stat Prozedural, wie Funktional oder Objektorientiert, etc. Eventuell andere Sprachen ausprobieren, die andere Konzepte aufweisen. Aber das wichtigste beim Lernen: Fehler machen! Nichts ist eindrücklicher, als wenn man das halbe Projekt umschreiben muss, weil man z.B. Header übermassig ineinander Inkludiert, ein Designproblem hat, oder sich auf eine nicht garantierte Annahme verlassen hat. In dem Sinne, zuerst mit Pointern herumschiessen, danach richtig machen ;) Zwischendurch sollte man eventuell noch einen Blick in den Standard werfen, besonders den Abschnitt mit undefined und implementation defined behaviour. Und einige Styleguids lesen. Es ist immer so Lästig wen man Code sieht, dessen Einrückung eher nach einem Wollknäul als nach strukturiertem Code aussieht... Und danach kann man C. PS: Den compiler immer auf maximale Fehlerintoleranz/Warnlevel einstellen und den Standard einstellen, mindestens c99 oder neuer. (z.B. gcc -Wall -Wextra -pedantic -Werror -std=c99)
Ich habe zuerst Assembler gelernt, dann Pascal, dann C und danach noch einige weitere Sprachen. Ich denke nicht, dass man zuerst Assembler lernen soll. Das schreckt nur ab. Bei mir hat es sich aufgrund der Rahmenbedingungen (C64) so ergeben. Da hatte man zu meiner Zeit nur die Wahl, ein unbrauchbares Basic zu verwenden oder manuell zu assemblieren. Aber wir haben heute keine C64er mehr auf dem Tisch stehen. Selbst ein Arduino Modul ist wesentlich fortgeschrittener, was die Programmierung angeht. Und das darf man auch gerne nutzen, finde ich. Erst nachdem man ein bisschen Programmiererfahrung gesammelt hat, halte ich es für empfehlenswert, ein kleines bisschen Assembler zu lernen.
Daniel A. schrieb: > Die Schwierigkeiten starten erst, wenn die Anfänger lernen > müssen, den Code zu Strukturieren, Konzepte wie OOP, Paradigmen wie > Statemachines, oder Datenstrukturen wie Verlinkte Listen und Stacks zu > lernen. HA! Genau an dem Punkt stehe ich gerade. ACK!
Kauf dir das XMC2GO für 7 € hat alles drauf was du brauchst: (ARM-Cortex-M0, Debugschnittstelle stronversorgung) http://shop.myavr.de/Hardware/XMC%202Go%20(KIT_XMC_2GO_XMC1100_V1).htm?sp=article.sp.php&artID=200128
Moby A. schrieb im Beitrag #4687252: > wo es (unnötig) schwierig wird muß man glaub ich nicht unbedingt > gelangen. Naja, wenn man nicht nur, sehr übertrieben gesagt, "eine LED zum blinken" bringen möchte, tut man sich mit OOP einfacher. Wenn man mal so ein paar Sachen geblickt hat, wird das um längen einfacher als mit plain-C. Es ist wie du sagst: Moby A. schrieb im Beitrag #4687252: > Nach C und anderen höheren Sprachen mit > ihren vielen Ausdrücken und komplizierten Konstruktionen hat es mich auf > einfacher Hardware wie dem AVR noch nie gedürstet Es kommt auf den Einsatzzweck an.
An der Uni fangen die im ersten Semester nicht umsonst mit SML an. Diese Denkweise der funktionalen Programmierung ist wirklich eines der wichtigsten Dinge die ein Programmierer lernen soll. Wenn du also gut Programmieren lernen willst dann beginne nicht mit Assembler sondern mit SML.
Uni iss ja auch praxisfremder Akademikerscheiß
axe schrieb: > An der Uni fangen die im ersten Semester nicht umsonst mit SML an. > Diese Denkweise der funktionalen Programmierung ist wirklich eines der > wichtigsten Dinge die ein Programmierer lernen soll. Wenn du also gut > Programmieren lernen willst dann beginne nicht mit Assembler sondern mit > SML. DoctorKnowItAll schrieb: > Uni iss ja auch praxisfremder Akademikerscheiß Genau, an der Uni lernt wird ja auch nicht "Programmierung" gelehrt sondern "Informatick". Programmieren muss man sich selber beibringen, bspw. durch embedded Hobbyprojekte auf mikrocontroller.net.
axe schrieb: > An der Uni fangen die im ersten Semester nicht umsonst mit SML an. > Diese Denkweise der funktionalen Programmierung ist wirklich eines der > wichtigsten Dinge die ein Programmierer lernen soll. Wenn du also gut > Programmieren lernen willst dann beginne nicht mit Assembler sondern mit > SML. Ein Schwachsinn, echt... :-D Der Prof gehört gefeuert!
axe schrieb: > Wenn du also gut Programmieren lernen willst dann beginne nicht mit > Assembler sondern mit SML. Das wird ja immer besser :D als ob C++ nicht schon übel genug wäre kommt jetzt auch noch so richtig abgefahrener Kram. Warum nicht gleich ABAP? In Giessen an der FH ist das der "Programmiergrundkurs" für die Wirtschaftsinformatiker. Die können nachher nur weder Wirtschaft noch Informatik (und programmieren schon gar nicht). Die können dann eigentlich nur SAP. *./* schrieb: > Um gute C++ Programme zu schreiben brauchst du kein ASM sondern musst > wissen wie man objektorientiert programmiert und keinen Spaghetti Code > produzieren. Auch wenn ich selber nicht so den riesengroßen Nutzen in Assembler sehe und zum Einstieg eher C nehmen würde, meine ich das Assembler einem (im Embedded Bereich) auf jeden Fall deutlich mehr bringt als C++. Ich weiß ehrlich gesagt nicht wie besoffen man sein muss um einen Mikrocontroller in C++ zu programmieren. Warum dann nicht gleich Java?
Christopher J. schrieb: > Ich weiß ehrlich gesagt nicht wie besoffen man sein muss um einen > Mikrocontroller in C++ zu programmieren Und ich frag mich wie bekifft man sein kann um mit plain-c ein gui zu programmieren :) Edit: warum nicht gleich mit asm? Oder gleich maschinencode.
:
Bearbeitet durch User
Christopher J. schrieb: > Warum nicht gleich ABAP? > ... wie besoffen man sein muss um einen Mikrocontroller > in C++ zu programmieren Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache. Für betriebswirtschaftliche Software ABAP (was wohl besonders Ei denen unbeliebt ist, die zusehen müssen, wie andere damit Geld verdienen) und für μC gerne C++ (denn auch da gilt, wenn man's kann, dann geht's sehr gut). C++ geht gut auf allem was ein GCC-Backend hat.
Carl D. schrieb: > Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache. "Nein?!" - "Doch!" - "Ohh!"
Reginald L. schrieb: > Carl D. schrieb: >> Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache. > "Nein?!" - "Doch!" - "Ohh!" Frag das doch mal den, der vorher anderes in den Raum gestellt hat.
Carl D. schrieb: > Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache. "Nein?!" - "Doch!" - "Ohh!" Carl D. schrieb: > Frag das doch mal den, der vorher anderes in den Raum gestellt hat. Du kennst dich wohl Louis de fines oder ;) https://youtu.be/w4aLThuU008
:
Bearbeitet durch User
Reginald L. schrieb: > Und ich frag mich wie bekifft man sein kann um mit plain-c ein gui zu > programmieren :) Ja ich weiß das C nicht das Allheilmittel ist und das die richtigen Druffies (besoffen und bekifft) den Mikrocontroller in C++ und die GUI in C programmieren :D Auch ABAP, SML und was auch immer mag alles seine Daseinsberechtigung haben aber meiner Meinung nach eben nicht im Bereich Mikrocontroller. Carl D. schrieb: > Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache. Für > betriebswirtschaftliche Software ABAP (was wohl besonders Ei denen > unbeliebt ist, die zusehen müssen, wie andere damit Geld verdienen) und > für μC gerne C++ (denn auch da gilt, wenn man's kann, dann geht's sehr > gut). C++ geht gut auf allem was ein GCC-Backend hat. Ja, auch mit COBOL kann man heute noch gut Geld verdienen und ich gönne es den Leuten die es machen. Ich würde nur keinem empfehlen damit programmieren zu lernen. Was C++ angeht sind die Geschmäcker ja bekanntlich verschieden und natürlich kann man einen uC damit befeuern. Ich persönlich halte es jedoch nicht für sinnvoll, weil C++ nur unnötige Komplexität rein bringt und zusätzliche Ressourcen frisst, die ohnehin schon sehr knapp sind. Aber jeder wie er will... Der TO wollte aber glaube ich C :D
:
Bearbeitet durch User
Christopher J. schrieb: > weil C++ nur unnötige Komplexität rein bringt > und zusätzliche Ressourcen frisst Nicht zwangsläufig. Das Problem dabei ist aber, daß man dann nicht nur wissen muß, wie man in C++ programmiert, sondern auch, was welche Ressourcen kosten. Der höhere Abstraktionsgrad von C++ wird da schnell zum Ärgernis, weil er vernebelt, statt zu helfen. Und dann muß man natürlich noch Programmierer haben, die auch dann noch gut mit C++ sind, wenn sie die Hälfte der Features nicht nutzen können und auch noch wissen müssen, welche. Fazit: Ein sehr guter C++-Entwickler bekommt Lösungen hin, die weder langsamer noch größer sind als gleichwertige Lösungen eines guten C-Entwicklers. Ein sehr guter C++-Entwickler kostet aber mehr als ein guter C-Entwickler, weil sehr gute Entwickler immer teurer sind als gute. Und zum Thema GUIs: Die hat man auf Mikrocontrollern normalerweise nicht. Kein einziges der Projekte, die ich beruflich je macht habe, hatte überhaupt ein Display. Die wurden gemacht, um irgendwo eingebaut zu werden und dann autonom ihren Dienst zu tun. Wenn man embedded programmieren lernen will, ist C++ jedenfalls IMO definitiv falsch, gerade weil es mehr abstrahiert - und damit gerade die Themenbereiche wegabstrahiert, über die man etwas lernen will.
Reginald L. schrieb: > Carl D. schrieb: >> Na ja, es gibt Leute, die benutzen jeweils eine geeignete Sprache. > "Nein?!" - "Doch!" - "Ohh!" > > Carl D. schrieb: >> Frag das doch mal den, der vorher anderes in den Raum gestellt hat. > > Du kennst dich wohl Louis de fines oder ;) > > https://youtu.be/w4aLThuU008 Ich kenn mich was? In welcher Sprache soll ich antworten? Es scheinen deutsche Worte zu sein, aber viele "Syntax Error"'s drin. BTW, den kleinen Franzosen kenn ich aus der Zeit, als er noch Filme gedreht hat, brauch also keine Details zu dem Spruch. Noch mal am Stück: ich habe einem geantwortet, der Programmiersprachen ungeachtet ihrer Geeignetheit für das jeweils zu lösende Problem bewertet hat. Bzw. ablehnt, weil sie ihm nicht gefallen. Oder wohl eher, weil er sie nicht versteht. Deshalb der von dir aus dem Zusammenhang zitierte Satz.
Moby A. schrieb im Beitrag #4688028: > Ein GUI lässt sich allerdings durchaus auch in Asm erstellen. Hab nie was anderes behauptet. Carl D. schrieb: > Ich kenn mich was? > In welcher Sprache soll ich antworten? Es scheinen deutsche Worte zu > sein, aber viele "Syntax Error"'s drin. Gnagnagna. Geil dich dran auf.
GUIs macht man in python als webinterface damit die Leute ihre Smart-Devices über Handy steuern können.
Christopher J. schrieb: > Was C++ angeht sind die Geschmäcker ja bekanntlich verschieden und > natürlich kann man einen uC damit befeuern. Ich persönlich halte es > jedoch nicht für sinnvoll, weil C++ nur unnötige Komplexität rein bringt > und zusätzliche Ressourcen frisst, die ohnehin schon sehr knapp sind. Entschuldige bitte, aber so pauschal gesagt ist das schlicht falsch. Es gibt C++-Features, auf die man in eng begrenzten Umgebungen wie einem Mikrocontroller besser verzichtet. Beispiele dafür sind die dynamische Speicherverwaltung und alles, was daran hängt: Exceptions, STL, etc. Aber auf kleinen Mikrocontrollern benutzt sowas ja auch niemand. Viele andere C++-Features, wie Klassen, Templates, Polymorphie und Vererbung lassen sich auch auf einem Mikrocontroller sinnvoll nutzen, und bringen dann dieselben Vorteile wie sonst auch: besser strukturierten, modularen, besser lesbaren und wiederverwendbaren, oft kompakteren Code. Und diese Features kosten, richtig angewendet, überhaupt keine zusätzlichen Ressourcen. Insofern muß man gar nicht "besoffen" sein, um C++ auf Mikrocontrollern zu nutzen. Ganz im Gegenteil muß man dazu nüchtern und fähig sein, und wenn man das ist, dann macht das sogar richtig Spaß.
DoctorKnowItAll schrieb: > GUIs macht man in python als webinterface damit die Leute ihre > Smart-Devices über Handy steuern können. Flask rult! ;-)
Angehängte Dateien:
-
IMG_20160817_183418.jpg
320 KB
Das Bild passt einfach perfekt. Aber bitte nicht falsch verstehen.
Und dann sollte man sich auch noch überlegen, daß OOP kein Allheilmittel ist und erst recht nicht "besser" als prozedural ist. Allerdings kann man auch in C objektorientiert programmieren, ich sag nur structs mit Funktionszeigern. Einen wirklichen Schub bringt es einem aber erst, egal ob C oder C++, wenn man OOP mal loslöst von der Syntax. Object.Function() ist schließlich nur syntaktischer Zucker für Function(&Object), das reißt keinen vom Hocker. Beispielsweise in einem RTOS mit verschiedenen Tasks, die kann man jeweils für sich als abstrakte Objekte sehen - und die sollten dann miteinander über klar definierte Interfaces reden, etwa mit Messages. Dann kann man die Arbeit auch gut parallelisieren, weil jeder seinen Task gegen die Spec seines Interfaces entwickelt. Zudem ist sichergestellt, daß interne Änderungen eines Moduls solange keine ungewollten Seiteneffekte haben, wie es seine Außenschnittstelle konstant hält. Das ist dann "private/public" in wesentlich größerem Maßstab, wo es auch was bringt. Das geht dann aber in C genausogut. Man sollte hierbei aber auch grundsätzlich mal sehen, wieso sich neuere Methoden als prozedurale Programmierung überhaupt erst entwickelt haben. Das war, wie zuvor ja auch die strukturierte Programmierung, eine Antwort auf zunehmende Komplexität. Nun ist auf Mikrocontrollern die Speichergröße normalerweise so übersichtlich wie auf Rechnern aus der Zeit, als prozedurale Programmierung aktuell war. Man wird nunmal keinen Clusterservice aus 200 Datenbankservern auf einem Mikrocontrollern laufen lassen und braucht daher auch nicht die Ansätze, die dort vernünftig sind. Umgedreht, wenn man mit Ansätzen für solche Anwendungen auf Mikrocontroller geht, schießt man mit Kanonen auf Spatzen, und während man den Aufwand dann immer noch hat, ist der Nutzen längst nicht so hoch wie bei den "großen" Anwendungen.
Christian B. schrieb: > Um C zu lernen musst Du aber erst mal ansatzweise Assembler können, > sonst wirst Du viele Sachen nicht verstehen. C ist eine Sprache die zum > Verständnis Assembler voraussetzt. Du musst auch erstmal zumindest eine Lehre als KFZ Mechaniker abgeschlossen haben, um Autofahren zu verstehen. Sicher ist es hilfreich, vor allem um zu verstehen wie der uC arbeitet, aber man kann sich auch später noch dafür interessieren. Wenn man anfängt, dann braucht man erst einmal schnelle Erfolge, damit man den Spaß nicht verliert.
Ich kann dir ein Entwicklungsboard für den Einstieg empfehlen. Ich persönlich finde den Intel Edison (mit Arduino Board) genial. Der Edison ist für Einsteiger und für den Einsatz in End-Produkten in kleiner Serie entwickelt und kompatibel zum Arduino. Die meisten (nicht alle) Arduino Shields können auch beim Edison verwendet werden und der Edison lässt sich auch mit der Arduino IDE programmieren. Und trotzdessen läuft auf dem Edison keine geflashte Firmware sondern ein komplettes 32-bit (x86) Betriebssystem (Yocto Linux), weshalb er dir viel mehr (!) Möglichkeiten und Komfort eröffnet als >nur< der Arduino. Technisches Datenblatt: https://cdn-shop.adafruit.com/datasheets/EdisonDatasheet.pdf (Der eigentliche Intel Edison ist nur das kleine Board unten links welches auf das Entwicklungsboard aufgesteckt wird. Das Entwicklungsboard ist Open Source. Der Edison ist per irgendwas Hirosestecke mit dem Board verbunden und kann auch mit einer eigenen Platine verbunden werden) Als Entwicklungsumgebgung kann eine modifizierte Eclipse IDE oder die Arduino IDE dienen. FAQ (Deutsch - aber mangelhaft übersetzt) http://www.intel.de/content/www/de/de/support/boards-and-kits/000005978.html Getting started: https://software.intel.com/en-us/node/544867 https://software.intel.com/en-us/iot/hardware/edison/dev-kit#
> Um C zu lernen musst Du aber erst mal ansatzweise Assembler können
Selten So einen Bullshit gehört.
> TheDarkNightRises schrieb:
PS: Da du Informatik studiert hast statt Elektrotechnik liegt
Embedded Programmierung auf Betriebssystem Ebene eigentlich auch
näher als auf Hardware Ebene.
DonKanaille schrieb: > tendiere ich aktuell zu dem LPC1549 Da der Frager sich schon lange für einen ARM entschieden hat ergibt die Diskussion nicht mehr viel Sinn ...
Nop schrieb: > Nicht zwangsläufig. Das Problem dabei ist aber, daß man dann nicht nur > wissen muß, wie man in C++ programmiert, sondern auch, was welche > Ressourcen kosten. Der höhere Abstraktionsgrad von C++ wird da schnell > zum Ärgernis, weil er vernebelt, statt zu helfen. > > Und dann muß man natürlich noch Programmierer haben, die auch dann noch > gut mit C++ sind, wenn sie die Hälfte der Features nicht nutzen können > und auch noch wissen müssen, welche. Das meinte ich auch unter anderem mit der Komplexität. Es reicht eben nicht einfach nur ein guter C++ Programmierer für Desktop-Software zu sein. Beschränkt man sich auf C hat man es etwas übersichtlicher. Sheeva P. schrieb: > Christopher J. schrieb: >> Was C++ angeht sind die Geschmäcker ja bekanntlich verschieden und >> natürlich kann man einen uC damit befeuern. Ich persönlich halte es >> jedoch nicht für sinnvoll, weil C++ nur unnötige Komplexität rein bringt >> und zusätzliche Ressourcen frisst, die ohnehin schon sehr knapp sind. > > Entschuldige bitte, aber so pauschal gesagt ist das schlicht falsch. > > Es gibt C++-Features, auf die man in eng begrenzten Umgebungen wie einem > Mikrocontroller besser verzichtet. Beispiele dafür sind die dynamische > Speicherverwaltung und alles, was daran hängt: Exceptions, STL, etc. Entschuldigung angenommen :D Natürlich war das etwas pauschalisiert. Sheeva P. schrieb: > Aber auf kleinen Mikrocontrollern benutzt sowas ja auch niemand. Wenn es doch nur so wäre. Natürlich macht es keinen Sinn diese Features zu nutzen aber als Anfänger durchzublicken welches Feature den Code aufbläht und welches nicht macht die Sache meiner Meinung nach einfach komplizierter. Sheeva P. schrieb: > Viele andere C++-Features, wie Klassen, Templates, Polymorphie und > Vererbung lassen sich auch auf einem Mikrocontroller sinnvoll nutzen, > und bringen dann dieselben Vorteile wie sonst auch: besser > strukturierten, modularen, besser lesbaren und wiederverwendbaren, oft > kompakteren Code. Und diese Features kosten, richtig angewendet, > überhaupt keine zusätzlichen Ressourcen. Genau da bin ich anderer Meinung, zumindest was Lesbarkeit und Wiederverwendbarkeit angeht. Vererbung halte ich (bis auf wenige Ausnahmen,z.B. GUI) für eine ganz schlechte Idee aber das ist wie gesagt Geschmackssache. Nop schrieb: > Allerdings kann man auch in C objektorientiert programmieren, ich sag > nur structs mit Funktionszeigern. Dito. Auch Interfaces sind in C kein Problem und spätestens seit 1973 mit open/read/write/close im Einsatz. Man muss natürlich wissen was "unter der Haube" eigentlich abgeht. Jetzt aber mal zurück zum Thema: TheDarkNightRises schrieb: > Technisches Datenblatt: > https://cdn-shop.adafruit.com/datasheets/EdisonDatasheet.pdf Da der TO wirklich tief in die Materie einsteigen will (Timer, Interrupts, etc.) kann ich persönlich (obwohl ich Linux mag) nur davon abraten so ein Intel Ding für erste Gehversuche zu nehmen. Auf der einen Seite ist der Overhead des OS mMn unnötig kompliziert und auf der anderen Seite darf sich dieses zweiseitige Etwas eigentlich niemals Datenblatt schimpfen. "Broschüre" wäre schon fast eine Übertreibung.
Moby A. schrieb im Beitrag #4689527: > Was Dir völlig abgeht ...kannst Du sicher nicht beurteilen. :-) > In der Medizin sagt man: Wer heilt hat recht, und genauso hier: Wer Spaß > an einer Sache hat der hat auch Recht damit, denn um Spaß gehts > letztendlich (oder sollte es gehen). Das gilt für Hobbyisten. Profis werden nicht dafür bezahlt, Spaß zu haben, sondern dafür, mit möglichst geringem Aufwand Produkte zu entwickeln, die sich gewinnbringend verkaufen lassen. Daß mir meine Arbeit obendrein Spaß macht, ist zwar sehr angenehm und erfreulich, am Ende aber doch nur eine Nebensache. > Tatsache ist nach wie vor, daß bei Embedded auf > MCs selbst anno 2016 die große Mehrheit auf prozedurale Programmierung > setzt- und da darf auch ein SheevaP davon ausgehen, daß dies seine (ganz > menschlichen) Gründe hat ;-) Das halte ich für ein Gerücht. Der Trend geht klar zu objektorientierten Techniken, nicht nur auf größeren Mikrocontrollern, sondern mittlerweile auch bei den kleinen. Häufig werden OO-Techniken sogar mit Sprachen wie C genutzt, die eigentlich keine direkte Unterstützung für OO mitbringen. Das kann nicht verwundern, ist die Objektorientierung letztlich nichts anderes als die Fortentwicklung und Erweiterung von Techniken und Entwurfsmustern, die sich seit Jahrzehnten bewährt haben. In der modernen Fachliteratur wie "Making Embedded Systems" und "21st Century C" wird das sehr ausführlich erläutert und begründet. Die Diskussion um OO ist heute letztlich dieselbe wie seit dreißig Jahren, hat sich aber verlagert: während früher in allen Umfeldern der Entwicklung über den Sinn, Zweck und Nutzen der OO diskutiert wurde, hat sie sich in der Breite nahezu überall durchgesetzt und die Diskussion beschränkt sich heute nurmehr auf kleine Nischen wie den Embedded-Bereich. Aber auch im professionellen Embedded-Umfeld sind objektorientierte Techniken längst zum Standard avanciert -- Grundsatzdiskussionen wie diese sehe ich heute im Wesentlichen nur noch mit Hobbyisten und Alteingesessenen, die (und da hast Du ausnahmsweise Recht, das sind tatsächlich zutiefst menschliche Gründe) nichts Neues mehr lernen wollen oder können. Allerdings ist es durchaus interessant, daß Du zur Begründung von primär technischen Entscheidungen auf menschliche Gründe zurückgreifen mußt. In technischer Hinsicht haben sich die Vorteile der OO offensichtlich längst erfolgreich durchgesetzt, ob es Dir gefällt oder nicht. :-)
Christopher J. schrieb: > Sheeva P. schrieb: >> Es gibt C++-Features, auf die man in eng begrenzten Umgebungen wie einem >> Mikrocontroller besser verzichtet. Beispiele dafür sind die dynamische >> Speicherverwaltung und alles, was daran hängt: Exceptions, STL, etc. > > Entschuldigung angenommen :D > Natürlich war das etwas pauschalisiert. > > Sheeva P. schrieb: >> Aber auf kleinen Mikrocontrollern benutzt sowas ja auch niemand. > > Wenn es doch nur so wäre. Natürlich macht es keinen Sinn diese Features > zu nutzen aber als Anfänger durchzublicken welches Feature den Code > aufbläht und welches nicht macht die Sache meiner Meinung nach einfach > komplizierter. Das gilt aber nicht nur für die OO, sondern überall, wo Abstraktion ins Spiel kommt. Auch in C gibt es Features, die den Code aufblähen, wie zum Beispiel die Funktionen der printf()-Familie oder Fließkommaarithmetik, letztere sogar in Abhängigkeit von der Zielplattform. OO heißt ja nicht, daß man sein Werkzeug nicht kennen muß. > Sheeva P. schrieb: >> Viele andere C++-Features, wie Klassen, Templates, Polymorphie und >> Vererbung lassen sich auch auf einem Mikrocontroller sinnvoll nutzen, >> und bringen dann dieselben Vorteile wie sonst auch: besser >> strukturierten, modularen, besser lesbaren und wiederverwendbaren, oft >> kompakteren Code. Und diese Features kosten, richtig angewendet, >> überhaupt keine zusätzlichen Ressourcen. > > Genau da bin ich anderer Meinung, zumindest was Lesbarkeit und > Wiederverwendbarkeit angeht. Vererbung halte ich (bis auf wenige > Ausnahmen,z.B. GUI) für eine ganz schlechte Idee aber das ist wie gesagt > Geschmackssache. Aus einer anderen Diskussion habe ich ein kleines Beispiel mitgenommen, wie OO mit wenig Aufwand besser les- und wartbaren Code ermöglicht: https://www.mikrocontroller.net/attachment/246051/main.cpp Dort wird die Vererbung benutzt, um die abstrakten, allgemeinen Namen der Parent-Methoden wie setHigh() und isHigh() in sprechende, zum betreffenden Objekt passende Namen wie gedrucket() und eingelegt() zu überführen, beim Instanziieren werden zudem die Objekte mit sprechenden Namen versehen. Durch diese extrem leichtgewichtige Abstraktion, die der Compiler restlos wegoptimiert, erkennt sogar ein Laie, der nicht programmieren kann und keine Ahnung von C hat, was in der main()-Funktion passiert. Klar: mit Makros und Funktionen kann man Ähnliches erreichen, aber dadurch wird es nicht lesbarer -- im Gegenteil: der Vorteil der OO ist an dieser Stelle, daß sie das menschliche Denken nahezu perfekt abbildet. Das ist natürlich nur ein einfaches Beispiel. Aber von grundsätzlichen Aussagen wie "XY halte ich für eine schlechte Idee" halte wiederum ich ziemlich wenig, auch und gerade in Bezug auf die Vererbung, welche durch vielfach unnötige, falsche Anwendung in Verruf geraten ist. Letztlich ist es damit ja wie mit jedem anderen Werkzeug: man muß immer wissen, welches für das konkrete Problem angemessen ist, und wie man es am Besten benutzt. (Soviel zum Thema Binsen.) ;-)
Moby A. schrieb im Beitrag #4692906: > Sheeva P. schrieb: > Alles dort wo es Sinn macht! Genau das sage ich doch. Schön, daß Du mir zustimmst. :-) >> und gerade in Bezug auf die Vererbung, welche durch >> vielfach unnötige, falsche Anwendung in Verruf geraten ist. > > Um Himmels Willen, wie konnte das bloß passieren??? Niemand hat behauptet, daß OO einfach wäre. Daß es zudem einen Hype gegeben hat, in dem jeder Marketing- und Management-Mensch seine Produkte mit dem modernen Nimbus der OO schmücken wollte, natürlich ohne dabei Zeit und Geld in ein sauberes OO-Refactoring investieren zu wollen, hat dazu geführt, daß oft lediglich alter, vorhandener Code sinn-, lieb-, plan- und konzeptlos in einen oberflächlichen OO-Rahmen gepreßt wurde, ohne jedoch die Konzepte der OO korrekt anzuwenden und ohne ihre Stärken wirklich zu nutzen. Das war der Technik und ihrem Ruf natürlich nicht gerade zuträglich. :-)
Moby A. schrieb im Beitrag #4693439: > Diese Schwierigkeiten sind der OOP selbst immanent. Nö. > Begreif das endlich. Nö. > Nix da mit "perfekter Abbildung" ! Statt dessen neue Bürokratie über > Bürokratie Nö. Daß Du es nicht verstehen willst und darum nicht mitreden kannst, ist erfreulicherweise nicht mein Problem. :-)
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.