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.