Objektorientiert?

[roubot]

Hallo
Ich möchte mit einigen Kollegen einen Roboter konstruieren.
Mit der Mikrochip-Programmierung kenne ich mich nicht aus, kann aber schon einiges mit C++. Die Frage ist nun welchen Chip und Programmiersprache wir verwenden sollten.
Da ich schon C++ beherrsche würde ich am liebsten eine Objektorientierte oder wenigstens C-ähnliche Sprache verwenden.
Folgendes Produkt ist mir aufgefallen: www.oopic. - hat schon jemand Erfahrung mit einem OOPic gemacht oder könnt ihr mir noch Tipps geben, welchen Mikrochip ich mir zulegen soll?

[Florian]

Hi!
Probier doch mal die AVR's mit C aus!

[muraad]

C++ und allgemein objektorientiert erzeugt meist zuviel Code für kleine 8Bit Mikrocontroller. Da braucht man schon eher ein 32Bit ARM Mikrocontroller mit "bisschen" mehr Flash-Speicher und Ram.
Gruß Muaad

[binaer]

Ich würde sowieso eine möglichst hardwarenahe Sprache empfehlen. Damit hat man die Maschine besser unter kontrolle (und weiss, was abläuft).
Wenn man C++ schon kann, ist ja C eigentlich nicht so weit ;) halt einfach ohne OOP. Ich persönlich bevorzuge aber für Mikrocontroller Assembler, aber das ist geschmackssache.
lg binaer

[bhm]

So ganz pauschal würde ich nicht sagen, dass OO / C++ mehr Speicher verbraucht als C. Einige Konstrukte wie Überladen, Konstruktoren, Destruktoren u.ä. sind wahrscheinlich nicht so günstig, aber Daten und Methode zu kapseln braucht erstmal keinen Extraspeicher und bringt viel an Übersichtlichkeit. Allerdings war ich bislang zu blöd WinAVR dazu zu bewegen C++ zu kompilieren. Soll aber, sagt man, gehen.
Im Übrigen finde ich immer noch, dass C eine Krankheit ist; C++ ist wenigstens schon ein Schritt in die richtige Richtung.
ciao .. bernd

[engineer]

Ui, nun wird es philosophisch. Ich gege Dir Recht, wenn Du die Vorteile von C++ gegen C herausstellst, da mit Bezug auf Verkapselung anders programmiert werden kann und muss. Mithin ist C++ entwickelt worden, um große Projekte zu handeln. Allerdings muss man dies von der Frage OOP oder nonOPP abgrenzen. OOP wird vielfach als das Besserer, Gutet und Ausgereifte dargstellet, was Mitnichten der Fall ist. Der C++ - Erfinder selber hat dazu ein cooles Statement gemacht.

OPP ist immer dann wirksam und angegracht, wenn tatsächlich abstrakte Eregnisse in unvorhersehbarer Zahl gehandelt werden müssen und z.B. ausgeprägtes Multitasking benutzt wird. C++ wiederum ist praktisch und vorteilhaft, wenn mit mehreren Programmieren an vielen Modulen gewerkelt werden soll, die noch wiederverwendbar sein sollen und / oder mit einem (RT-)-Betriebssystem gearbeitet werden soll oder muss, daß C++ fordert oder unterterstützt.

Gerade Letzteres ist der entscheidende Aspekt: ASM und C ermöglichen zwar eine objektorientierte Programmierweise und erlauben selbstredend auch Multitaskingarchitekturen, aber sie unterstützen es nicht. Daher sind in ASM oder C gestrickte MT-Architekturen nur singulär nutzbar, während C++ ein gemeinsame Sprachbasis liefert, die zumindest ein gewisse Universalität und damit Weiterverwendbarkeit des Codes schaft.

[bhm]

Ist alles richtig.
Generell ist (finde ich) OO oder prozedual eher eine philosophische und Übungsfrage. Immer wenn ich mal wieder denke ich sollte mal was richtig mit OO (meist Delphi) machen fallle ich meinen alten prozedualen Stil mit etwas OO-Verzierung zurück.
Für kleine (und 8k Programme sind klein) Projekte und erst recht One-Man-Shows ist OO ziemlich übertrieben. Nur manchmal ist ein Objekt bei dem seine Methoden nur auf seine Variablen zugreifen können doch praktischer als losgelöste globale structs und Prozeduren.
Bei _richtigen_ Projekten mit mehreren Programmierern gibt es zu sauberer Kapselung keine vernünftige Alternative.
Was die event-Behandlung betrifft weis ich garnicht (kenne ich mich einfach nicht aus) ob das zur OO im eigentlichen Sinn gehört. Das wäre für µC-Programmierung natürlich supernützlich, produziert dann aber für die kleinen Dinger doch zuviel Code.
Was mich an C (obwohl ich es benutze) stört sind die erweiterten Möglichkeiten Fehler einzubauen: Keine / kaum Typüberprüfung, range-checks (geht aber eh nur mit einem Runtimesystem) und diese fehlerträchtige Syntax ( while ( a=*b++ ) .... ). Muss man nicht machen, aber dann ist der Code teilweise nicht mehr optimal, sigh ..
ciao .. bernd

[engineer]

Um es mal konkret zu sagen: Robotersteuerungen in Software handlen keine massenweise Objekte. Es gibt an Industrierobots bestenfalls Einige Bedienknöpfe, deren events ereignisorientiert abgearbeitet werden müssen, ferner könnte man bei Visualisierungen in Display Regionen einführen, die einzelene Darstellungscharkatäre besitzen. LEDs könnten auch Objekte sein. All dies könnte ein OO Vorgehensweise rechtfertigen.

Praktisch vollziehen Robots jedoch Prodezeduren und direkt deterministisch festgelegte Handlungen und Reaktionen. (US-Sensor plärrt, ergo nach links ausweichen). Damit ist für mich klar, was da wie zu programmieren ist.

Ausserdem: Noch vor Jahren hatten wir ja die Theorie, daß es keine Programmsprünge geben darf und alles in Schleifen laufen müssen. Listenprogrammsprachen wurden erfunden und Vieles mehr an theoretischem Ballast aufgetürmt.

Momentan ist eben OOP angesagt, aber das wird sich sicher bald relativieren.

[bhm]

Ausserdem: Noch vor Jahren hatten wir ja die Theorie, daß es keine Programmsprünge geben darf und alles in Schleifen laufen müssen.
naja, hin-und-her-Gespringe macht den Code definitiv schwer lesbar. Auch wenn es dem Prozessor egal ist und es an einigen Stellen eher uneffektiv ist, vermeide ich es von gelegentlichen breaks abgesehen.
ciao .. bernd

[PicNick]

Das ganze formale Zeugs wird erst interessant, wenn du eines deiner eigenen 748 Programmen nach einem Jahr irgendwie warten mußt.
da würdest du dich wundern, wie fremd dir dann das alles ist.

[engineer]

bhm: Wie erarbeitet man sich eigentlich einen Programmabluaf bei einem OOP-Proramm? ;-)

Robert, Du hast sehr Recht: Ich habe mal kürzlich meine alten ASM-Programme für den C64 aufgeholt: Um Himmelswillen, damals hatte ich Programmiertricks drauf! Ich muss selber überlegen, was ich da verbrochen habe :-)

[PicNick]

bhm: Wie erarbeitet man sich eigentlich einen Programmabluaf bei einem OOP-Proramm?
Eben gar nicht. D.h man geht nicht vom Ablauf aus, sondern erstmal von den Bestandteilen, die beteiligt sind. Die haben eben bestimmte verschiedene und gemeinsame Eigenschaften (Attribute) und irgendwelche Methoden, mit denen umzugehen.
Beim Roboter kannst du (z.B) einfach von den HW-Geräten ausgehen,
die sind erstmal ganz einfach Geräte , dann unterteilt in Aktoren und Sensoren und so geht's weiter.
Was für Methoden die haben, kannst du dir ja vorstellen.
Und wichtig ist, daß eben keiner dem anderen in seiner Klasse rumfummelt, sondern alles geht über wohldefinierte Schnittstellen.
Und erst dann kommt der eigentliche Ablauf ins Spiel.
So wie bei Otto Waalkes: "Großhirn an alle: Ärgern!"

Das ist aber eine extreme Kurzversion, das ist schon klar

[engineer]

PicNick, DIES genau war der Grund meines Einwurfes. Einem OOP kann man den Ablauf nicht entnehmen. Damit ist dies im Ggs zu dem oben Gesagten: (strukturiereter, kein rumgespringe ..) eben zunächst NICHT strukturierter in C++ oder OOP zu programmieren. Einem prozeduralen C-Programm kann ich die Abläufe eher ansehen.

Daher ja inzsichen auch der Ansatz mit UML um Abläufe und User-Aktivität in den Griff zu bekommen.

Arbeitet hier eigentlich jemand mit einem geschlossenen System aus OOD (mit UML) für den embedded-Bereich ?

[bhm]

Das ganze formale Zeugs wird erst interessant, wenn du eines deiner eigenen 748 Programmen nach einem Jahr irgendwie warten musst.
da würdest du dich wundern, wie fremd dir dann das alles ist.
So lange brauche ich garnicht warten. Am besten ist sind regular expressions in perl, die einzige write-only-Programmiersprache. ;-)


Einem OOP kann man den Ablauf nicht entnehmen. Damit ist dies im Ggs zu dem oben Gesagten: (strukturiereter, kein rumgespringe ..) eben zunächst NICHT strukturierter in C++ oder OOP zu programmieren. Einem prozeduralen C-Programm kann ich die Abläufe eher ansehen.
Wahrscheinlich werden deshalb meine OOP immer irgendwie prozedual. Ich denke einfach eher prozedual (Männer können kein Multitasking)
;-)
Aber noch zwei Bemerkungen:
a) Die Methoden selbst sind dann doch wieder Prozeduren.
b) Wer's kennt; den Unterschied (OO - proz) kann man prima sehen, wenn man Testpoint und Labview vergleicht. Beide sind dasselbe: Graphische Programmiersprachen für Mess- und Regelanwendungen. Testpoint ist event-orientiert, einem Tastendruck wird eine bestimmte Operation zugeordnet. Labview ist streng prozedual, visualisiert durch Daten die über Leitungen "laufen". Da muss man den Tastendruck halt pollen.
Hat alles Vor- und Nachteile.

ciao .. bernd

[engineer]

Einwurf: Auch wenn es meiner obigen Argumentation scheinbar entgegenläuft: Ich bevorzugte schon immer Testpoint!

[PicNick]

Berufsbedingt kann ich es mir nicht leisten, die Theorie über die Praxis zu stellen, was aber nicht als Wertung zu verstehen ist. Ich persönlich pick' mir aus dem ganzen Angebot immer das raus, was ich als nützlich erachte und was dem Ziel angemessen ist.
Einen "Roboter" in streng gekapselte Trümmer auzuteilen, die untereinander Messages austauschen, halte ich für äußerst nützlich, die Gauß'sche Osterberechnung würd' ich aber eher prozedural sehen.
Wie gesagt, ich will das aber keinem einreden.

[bhm]

Einwurf: Auch wenn es meiner obigen Argumentation scheinbar entgegenläuft: Ich bevorzugte schon immer Testpoint!
Das Strippenziehen in Labview macht mich wahnsinnig. Aber die Grafik von Labview ist schöner ;-)
ciao .. bernd

[engineer]

Naja, ich war auch mal Labview-Fan, habe mich aber davon wegentwickelt. Ich entwickle oft mit wxWigets, wo z.B. die serielle LIB inzwischen auch GPIB-Unterstützung hat. Das (C++ progrmamieren) ist am Ende effektiver und flexbiler, wenn man einigermassen programieren kann (was die meisten ja können) und hat auch Vorteile beim Validieren und der Integration autoamtischer Testfunktionen. Kennt man sich mit der wxwidgets-GUI erst mal ein wenig aus, ist das ähnlich flexibel und schnell erstellet wie Labview, nur läuift es dreimal so schnell, man unterliegt nicht den Restriktionen von LV und es läuft auf ALLEN Platformen! Ausserdem ist es RICHTIGES OOP :-)

http://home.arcor.de/juergen.schuhmacher/programming%20with%20wxwidgets.html

GPIB-Support mit CTB: http://www.iftools.com

Ach ja, Picnick: Wir wissen immer noch nicht, WAS Du Deiner Mietzekatze verabreicht hast.

[PicNick]

Ach ja, Picnick: Wir wissen immer noch nicht, WAS Du Deiner Mietzekatze verabreicht hast.
Wenn du Katzen kennst, weißt Du, daß das ein normales Alltagsfoto ist. Manche finden es einfach cool, so dazusitzen wie ein besoffener Bierkutscher und geistlos (mit screensaver im Hirn) dreinzuschauen und sich nicht stören zu lassen.
Einer Katze braucht Du nichts zu geben, die sind von selber so. (Anwesende ausgenommen, natürlich)
Tut mir leid, Du mußt die selber den geeigneten Stoff suchen

[engineer]

ok, ich hatte noch nie eine Katze - finde die Info aber sehr interessant!
(Bierkutscher :-))