Embedded-Programmierung -> Yay or nay

[sdf]

Minimee schrieb:

sdf schrieb:

volkard hat da nicht ganz unrecht.

Für die Programmierung von µC muß man oft nur ganz einfache Prozeduranweisungen schreiben. Sprich, wenn an Pin x ne 1 anliegt, mache dann dies und gebe XY über Pin x2 aus. Und Timerbrechnungen usw. gehen in den Alltag über.

Das ist doch Bullshit, ihr habt nur keine Ahnung davon. Vielleicht wenn man nen Kaffeemaschinen-uC programmiert, aber die Algorithmen für Regelungen im Auto/Flugzeug/Drehstrommaschinen gehen weit, weit über den Ansrpuch einer Grafik-Library hinaus, für die man gerade mal Oberstufen-Mathematik benötigt.

Wie ich schrieb gibt es Ausnahmefälle, wie eben ESP.
Aber die Regel ist das nicht.

Das meiste ist simple Regelungstechnik für ne Waschmaschine, die Heizung im Keller usw.

Und eine einfache Grafiklibrary ist noch lange keine 3d Engine.

[sdf]

Bashar schrieb:

Minimee schrieb:

die Algorithmen für Regelungen im Auto/Flugzeug/Drehstrommaschinen gehen weit, weit über den Ansrpuch einer Grafik-Library hinaus, für die man gerade mal Oberstufen-Mathematik benötigt.

Du vergleichst jetzt den mathematischen (bzw. eigentlich fachlichen) Anspruch mit dem Programmieranspruch. Die Behauptung sdfs, es sei nur ganz einfaches Manipulieren irgendwelcher Ports ist prinzipiell richtig, was macht denn ein Regelalgorithmus? Er wird periodisch aufgerufen, liest ein paar Werte ein, rechnet ein bisschen rum (jaja das WIE ist die Kunst, aber das ist am Ende halt auch nur eine Formel und ein bisschen Zustandslogik), speichert etwas ab und schreibt die Ergebnisse raus. Programmiertechnisch ist das überhaupt nicht anspruchsvoll. Darf es ja eigentlich auch nicht, es muss einfach sein, um stabil zu laufen. Der Anspruch liegt wie gesagt im Entwickeln der Regelung, außerdem im Scheduling, in der Kommunikation und in der Robustheit gegenüber Ausnahmezuständen.
Ich hab hin und wieder mit Sachen aus der Autoindustrie zu tun, und was ich da sehe, haut mich -- der programmiertechnische Teil -- absolut nicht vom Hocker. Ich glaube die Leute sehen Programmierung als notwendiges Übel an, das irgendwo zwischen Entwurf und Testen gequetscht wird. Die Qualität (oder was man dafür hält) wird durch rigide Formvorschriften sichergestellt. Ich würde da nicht als Programmierer arbeiten wollen.

Danke, genau so ist es.

[this-*gt*that]

Übersetzung: Dädädä, was ich mach is viel komplizierter!111111

[KennerDerVolksARD]

SideWinder schrieb:

Ich weiß nicht was du mit "typische Game-Coder" meinst, aber im Bereich der professionellen Spieleprogrammierung sind doch oftmals sehr gute, auch theoretisch sehr fundierte Personen unterwegs. Du redest aber dann wohl eher von "I want to do WoW until next weekend"-Personen?

Volkard hat nur immer noch nicht verkraftet, dass TGGC deutlich besser und erfolgreicher ist als er.

[Herkules]

KennerDerVolksARD schrieb:

SideWinder schrieb:

Ich weiß nicht was du mit "typische Game-Coder" meinst, aber im Bereich der professionellen Spieleprogrammierung sind doch oftmals sehr gute, auch theoretisch sehr fundierte Personen unterwegs. Du redest aber dann wohl eher von "I want to do WoW until next weekend"-Personen?

Volkard hat nur immer noch nicht verkraftet, dass TGGC deutlich besser und erfolgreicher ist als er.

Ist das der TGGC?
http://www.games-net.de/hosted/tggc/index.php?cat=1&page=8

Wenn ich mir das Foto so ansehe, dann könnte man glatt meinen, daß er eine gewisse Ähnlichkeit mit Q hat:
http://phoenixdjt.tripod.com/images/q.jpg

[Gast]

Das ist doch jetzt wirklich der reinste Schwanzvergleich hier!!

Die Mikrocontroller Programmierung wirkt anfangs etwas befremdlich, insgesamt ist sie aber recht einfach. Das wirklich komplizierte ist die Logik dahinter, also das, was zwischen dem Einlesen und Rausschreiben der Daten passiert.
Und nicht selten sind da ziemlich komplizierte Regler einprogrammiert.
Das ist das komplizierte. Oder eben digitale Filter bzw. Signalverarbeitung. Das schwierige sind da die mathematischen/physikalischen Dinge. Das Runtertippen in C ist dann zum Glück nicht schwer da man meist mit +-*/ und einigen Variablen auskommt!

Übrigens ist die Programmierung unter Elektrotechniker oft nur ein Mittel zum Zweck, quasi eine Übersetzung der Mathematik in die Computersprache, Hauptsache das Zeug funktioniert. Informatiker sehen programmieren eher wie Gedichte schreiben, das ganze (also der Programmierstil) muss gewissermaßen "schön" sein.

[volkard]

Ist das da http://www.c-plusplus.net/forum/289659 Embedded-Programmierung?

[Hihi]

Was hat Programmieren jetzt eigentlich mit Informatik zu tun? Einen Mikrocontroller ansteuern kann doch jeder, dafür muss man kein Informatikstudium absolviert haben.
Vielleicht mal nebenher, irgendwer muss es ja machen - aber Hauptberuflich?!

/OT: Was bei der (http://www.games-net.de/hosted/tggc/index.php?cat=1&page=8) Aufzählung fehlt ist: TGGC kann "Maschine" nicht richtig schreiben.

(

TGGC schrieb:

TGGC ist Turingmaschienen äquivalent

)

[Minimee]

volkard schrieb:

Ist das da http://www.c-plusplus.net/forum/289659 Embedded-Programmierung?

Ganz sicher nicht, ein echter Embedded-Programmierer verwendet niemals floating-Point Arithmetik
Außerdem ist das scheußlich.

[volkard]

Minimee schrieb:

volkard schrieb:

Ist das da http://www.c-plusplus.net/forum/289659 Embedded-Programmierung?

Ganz sicher nicht, ein echter Embedded-Programmierer verwendet niemals floating-Point Arithmetik
Außerdem ist das scheußlich.

Oh, dann werden manche Embedded Systems also mit Embedded-Programmierung gemacht und manche Embedded Systems anders. Das erklärt schonmal einige Widersprüche.

[Minimee]

volkard schrieb:

Minimee schrieb:

volkard schrieb:

Ist das da http://www.c-plusplus.net/forum/289659 Embedded-Programmierung?

Ganz sicher nicht, ein echter Embedded-Programmierer verwendet niemals floating-Point Arithmetik
Außerdem ist das scheußlich.

Oh, dann werden manche Embedded Systems also mit Embedded-Programmierung gemacht und manche Embedded Systems anders. Das erklärt schonmal einige Widersprüche.

Hm? Es gibt sicher Embedded-Systeme auf denen sich ein gelernter PC-Frickel Programmierer austobt, trotzdem wird das dann im Allgemeinen nicht so gemacht wie er es vielleicht macht.

[HoHo]

Hihi schrieb:

/OT: Was bei der (http://www.games-net.de/hosted/tggc/index.php?cat=1&page=8) Aufzählung fehlt ist: TGGC kann "Maschine" nicht richtig schreiben.

(

TGGC schrieb:

TGGC ist Turingmaschienen äquivalent

)

Die Fakten kann jeder eintragen.

[StefanS]

sdf schrieb:

volkard hat da nicht ganz unrecht.

Für die Programmierung von µC muß man oft nur ganz einfache Prozeduranweisungen schreiben. Sprich, wenn an Pin x ne 1 anliegt, mache dann dies und gebe XY über Pin x2 aus. Und Timerbrechnungen usw. gehen in den Alltag über.
All das kann Spaß machen, weil es recht hardwarenah ist, aber es ist vom Programmieren her betrachtet dennoch trivial.

Ganz anders sieht das schon bei der Entwicklung einer 3d Engine aus.
Da geht es erst richtig los mit der Speicherverwaltung, der Verwaltung von Objekten, den Matrizenberechnungen usw..

Auch der Umfang an Stoff den man können muß, ist bei letzterem viel umfangreicher.
µC kann man im Prinzip schon programmieren wenn man
A) ein bischen Assembler gelernt hat (dient dem Verständnis),
die Programmiersprache C kann
C) sich mit dem jeweiligen µC auseinandergesetzt hat

Bei 3d Engines ist man mit C und OpenGL/Direct3d noch längst nicht am Ziel.
Von da geht es dann weiter mit Scene Graphen, Sichtbarkeit von Objekten, möglicherweise auch Kollisionserkennung usw..
Und die ganzen Grundlagen aus dem Infostudium wie Datenstrukturen, Mathe und co braucht man sowieso.

All das braucht man bei µC nicht.
Lediglich Datenstrukturen können noch hilfreich sein.
Für die Mathe reicht in den meisten Fällen die Schulmathematik bis zur 13.

Die Programmierung von µC ist aus Informatikersicht also nicht schwer und genau aus diesem Grund werden µC auch schon von Leuten programmiert, die Elektrotechnik studiert haben.
Das kann man sich nämlich alles nebenbei beibringen.
Prinzipiell reicht dafür schon ein Schüler aus, der in der Freizeit C und etwas Assembler gelernt hat.

PS: Natürlich gibt es auch Spezialfälle wie ESP, die die Funktionalität und das notwendige Wissen für das Programmieren eines µC für eine Kaffemaschine deutlich übersteiegn, aber das sind eben die Ausnahmen von der Regel.

Ja es ist wahr, dass Mathematiker, Physiker, Regelungstechniker geistig im Stande sind großartige theoretische Leistungen zu vollbringen.
Es ist aber auch wahr, das von diesen Theoretikern fast niemand im Stande ist das dann auch in angemessener Zeit und in angemessener Qualität in die Praxis umzusetzen.

Softwareentwicklung ist in der Theorie ja sehr einfach.
1. Man implementiert Software
2. Man schreibt Softwaretests
3. Man macht statische Codeanalyse
Und schon kann man das Produkt fast ausrollen.
In der Praxis ist aus wirtschaftlichen Gründen der Zeitdruck so immens das oftmals gerade noch für Punkt 1 Zeit ist. Alles andere zerbröselt dann.
Die meisten Softwaretests testen dann sowieso nur den Teil ab der funktioniert. Die Fehlerhafte Implementierung gammelt dann im Code vor sich hin.

Fakt ist auch, das wirklich gute Softwareentwickler schwer zu finden sind. Deswegen wird teilweise auf oben genannte Autodidakten zurückgegriffen. Wer schonmal mit solchen Leuten zusammen gearbeitet hat, der weiß, dass gute Softwareentwickler unter Autodidakten noch viel schwieriger zu finden sind als "studierte" Informatiker die in der Softwareentwicklung arbeiten.

In der Theorie mag Softwareentwicklung für Embedded Systeme für manche Leute trivial sein. Diese Leute haben aber noch NIE in ihrem Leben intensiv Software für Embedded Systeme entwickelt. Die ganzen technischen Hürden bei der Entwicklung, angefangen bei grottenschlechten Entwicklungstools über Bugs in den Mikrocontrollern bis hin zu mangelhaften Platinenlayouts die negative Seiteneffekte auf die Software haben. Wisst ihr was da die ganzen guten Theoretiker machen? Die haben nach 10 Minuten keinen Bock mehr darauf

Und die Zeiten, wo Embedded Systeme popelige I/O geräte mit Regler sind die sind doch auch schon lange vorbei.

Überlegt mal wo überall komplexere Embedded Systeme existieren. Drucker, Kameras, Smartphones, Navigationssysteme, Home Entertainment im KFZ, Router.

Es ist gut und wichtig, dass es Physiker, Mathematiker mit großen theoretischen Leistungen gibt. Man muss sich aber auch vor Augen halten, dass die allerwenigsten davon auch nur im Ansatz geeignete Softwareentwickler sind.

[Gast]

volkard schrieb:

Naja, loben wir mal nicht zu viel. Man sieht regelmäßig in Diskussionen, daß die Embedded-Leute oft genug sogar noch weniger Ahnung haben als typische Gamecoders und noch eingebildeter von sich sind.

Ahnung von was?

[Dravere]

sdf schrieb:

Für die Programmierung von µC muß man oft nur ganz einfache Prozeduranweisungen schreiben. Sprich, wenn an Pin x ne 1 anliegt, mache dann dies und gebe XY über Pin x2 aus. Und Timerbrechnungen usw. gehen in den Alltag über.
All das kann Spaß machen, weil es recht hardwarenah ist, aber es ist vom Programmieren her betrachtet dennoch trivial.

Ganz anders sieht das schon bei der Entwicklung einer 3d Engine aus.
Da geht es erst richtig los mit der Speicherverwaltung, der Verwaltung von Objekten, den Matrizenberechnungen usw..

Selten so gelacht! Hast du schon mal im Embedded Bereich entwickelt? Scheint mir irgendwie nicht der Fall zu sein.

Erst bei einer 3D Engine soll es richtig losgehen mit der Speicherverwaltung? Ich möchte dich darauf hinweisen, dass auf Embedded Systemen dem Programmierer jedes Byte gestohlen wird, damit man weniger Speichermodule verbauen muss. Speicherverwaltung kann sehr schnell sehr mühsam werden auf dem uC. Denk nur mal daran, dass man auf einer 8 Bit CPU meistens ca. 128 Byte Stackspeicher zur Verfügung hat und es können jederzeit noch Interrupts reinkommen. Wenn du nicht höllisch aufpasst, hast du schnell einen Stackoverflow und diesen auf einem Embedded System zu finden, ist recht mühsam. Allgemein muss die Ressourcen-Verwaltung sehr sorgfältig durchgeführt werden. Du bist auf allen Seiten begrenzt. Du musst das System optimal ausschöpfen und bei kritischen Systemen dann noch garantieren, dass es genügend nach oben hin frei hat. Wer da nur ein wenig rumfrickelt, hat keine Chance. Wenn du nur ein paar LEDs ansteuerst, ja, dann ist jeder uC völlig überdimensioniert, keine Frage. Aber schau dir z.B. verteilte Systeme an, z.B. im Bereich der Haustechnik verbunden über ZigBee. Da kommst du dann auch in Dinge rein wie VKI (Verteilte Künstliche Intelligenz). Und du hast keinen Schachcomputer zur Verfügung sondern alles Systeme mit sehr schwacher Leistung. Ich habe da schon Dinge gesehen, wo die Rechnerlast auf die verschiedenen zur Verfügung stehenden Module verteilt wurde. Ein wenig blöd ausgedrückt, wenn die Mikrowelle zu viel Last hatte, wurden Teile an den Kühlschrank zur Berechnung übergeben. Das sind komplexe Informatiksysteme, welche nichts mit "Pin x auf 1 oder 0 setzen" zu tun haben.

Natürlich gibt es auch triviale Programme auf Embedded Systemen. Aber es gibt auch triviale Programme auf dem PC. Beide Systeme haben Bereiche mit Herausforderungen und Bereiche ohne Herausforderungen. Aber deine Vorstellung von Embedded-Programmierung halte ich für ein wenig sehr naiv und kurzsichtig.

Grüssli

[volkard]

Dravere schrieb:

dass man auf einer 8 Bit CPU meistens ca. 128 Byte Stackspeicher zur Verfügung hat

Dravere schrieb:

wenn die Mikrowelle zu viel Last hatte, wurden Teile an den Kühlschrank zur Berechnung übergeben

Nett in einem Atemzug erzählt.

[sdf]

Dravere schrieb:

sdf schrieb:

Für die Programmierung von µC muß man oft nur ganz einfache Prozeduranweisungen schreiben. Sprich, wenn an Pin x ne 1 anliegt, mache dann dies und gebe XY über Pin x2 aus. Und Timerbrechnungen usw. gehen in den Alltag über.
All das kann Spaß machen, weil es recht hardwarenah ist, aber es ist vom Programmieren her betrachtet dennoch trivial.

Ganz anders sieht das schon bei der Entwicklung einer 3d Engine aus.
Da geht es erst richtig los mit der Speicherverwaltung, der Verwaltung von Objekten, den Matrizenberechnungen usw..

Selten so gelacht! Hast du schon mal im Embedded Bereich entwickelt? Scheint mir irgendwie nicht der Fall zu sein.

Also so etwas finde ich schon doof, erst fragst du mich, ob ich überhaupt im Embedded Bereich entwickelt habe, aber dann fällst du gleich im selben Augenblick ein Urteil bevor du überhaupt eine Antwort darauf erhalten hast.

Ich denke bei so einem "Was nicht sein darf, darf nur so sein"-Denken, kann ich mir eine Antwort auf deine Frage auch sparen, denn du wärst damit nicht zufrieden.

Erst bei einer 3D Engine soll es richtig losgehen mit der Speicherverwaltung? Ich möchte dich darauf hinweisen, dass auf Embedded Systemen dem Programmierer jedes Byte gestohlen wird, damit man weniger Speichermodule verbauen muss. Speicherverwaltung kann sehr schnell sehr mühsam werden auf dem uC. Denk nur mal daran, dass man auf einer 8 Bit CPU meistens ca. 128 Byte Stackspeicher zur Verfügung hat und es können jederzeit noch Interrupts reinkommen. Wenn du nicht höllisch aufpasst, hast du schnell einen Stackoverflow und diesen auf einem Embedded System zu finden, ist recht mühsam. Allgemein muss die Ressourcen-Verwaltung sehr sorgfältig durchgeführt werden.

Speicherverwaltung != Speicherverwaltung.

Ich denke du bist dir nicht im klaren, was Speicherverwaltung beim Schreiben von 3d Engines bedeutet, weswegen du hier nun auf hiesige Trivialitäten verweist.

[Dravere]

sdf schrieb:

Also so etwas finde ich schon doof, erst fragst du mich, ob ich überhaupt im Embedded Bereich entwickelt habe, aber dann fällst du gleich im selben Augenblick ein Urteil bevor du überhaupt eine Antwort darauf erhalten hast.

sdf schrieb:

Ich denke du bist dir nicht im klaren, was Speicherverwaltung beim Schreiben von 3d Engines bedeutet, weswegen du hier nun auf hiesige Trivialitäten verweist.

Du bist mein Held! Ich habe kein Urteil gefällt, nur eine Annahme getroffen. Genau wie du es im zweiten Zitat auch tust und dabei allerdings völlig daneben liegst.

Naja, jedenfalls danke für den Lacher Prediger sdf.

Grüssli