peinliche Frage zur Objektorientierung

ich denke, das krieg ich schon hin.
woran es mir fehlt, ist eine doku, wie das bedientechnisch in arv-studio 
geht.

in vb2010 (auch auf visual studio) muß man die selber erzeugten
klassen im projektordner als verweis (.dll) einfügen.

wie geht das hier ??

ok, ich sollte präziser formulieren, stimmt schon.

also : ich wil eine klassenbibliothek schreiben, die alle details der 
peripheriebedienung vom anwendungsprogrammierer (das sind später 
schüler) fern hält. der soll sich auf regelalgorithmen und filter und 
sowas konzentrieren.

.. jetzt präzise : wie erzeugt man in avr-studio eine klassenbibliothek 
(.dll ?) oder : wo ist sowas dokumentiert ??

Reiner Doll schrieb:
> .. jetzt präzise : wie erzeugt man in avr-studio eine klassenbibliothek
> (.dll ?) oder : wo ist sowas dokumentiert ??

Eine DLL ist ein ausführbares Programm, aber auf dem AVR können nicht 
mehrere Programme laufen.
Man muß also eine Lib nur als Objekt kompilieren und dann dazu linken.

Ob C oder C++ spielt für die Lib-Erstellung keine Rolle.

http://www.mikrocontroller.net/articles/Libraries


Peter

Reiner Doll schrieb:

> wie erzeugt man in avr-studio eine klassenbibliothek (.dll ?)

Das ist nicht was di willst. Auf einem AVR einen dynamischen Linker 
laufen zu haben wäre ein ziemlicher Overkill...

Was mir auch seltsam vorkommt, ist der Grund für die Lib: Wissen von den 
Schülern fernhalten. Wenn sie über den Tellerrand blicken möchten, warum 
denn nicht?

weils ums eigentliche programmieren noch nicht geht.

c können die jungs schon, es ist eine prinzipielle frage, ob
c++ mit der objektorientierung (rudimentär !) eine vereinfachung
des programmierkonzepts für die schüler darstellt.

deshalb hier ein paar versuche ... die leider mangels bedienknow-how
zäh laufen.

deshalb die frage : wo ist die oo-programmierung n avr-studio 
dokumentiert ?

Gar nicht.

Zu C++ gibt es hier schon ein paar Kommentare, die Foren-Suche sollte da 
helfen.

zu Libs:
Eine DLL bzw. ein shared object (Unix-Pendant dazu) kann man nur nutzen, 
wenn man ein Betriebssystem aht, das dies auch unterstützt. Das wird auf 
einem AVR nicht der Fall sein. weil es da gar kein OS gibt.
Die einzige Alternative ist eine statische Bibliothek, das kann man hier 
nutzen bei Bedarf.

da hätt ich selber draufkommen können, oh weh.
ich hab zu lange nix mehr mit controllern gemacht, da ist windows zu 
tief im kopf eingebrannt ;-)

also mach ich eine .cpp als static lib project, nenn die .h, include die
oben und  .... referenziere ?

Ob die Erstellung von Libs irgendwie im AVR-Studio direkt unterstützt 
wird, weiß ich nicht, weil ich nicht mit dem arbeite.

Wenn man sich dazu herablässt, selbst makefiles zu schreiben, nimmt man 
dafür avr-ar.

Wenn der normale Weg für drei Quelltexte (zwei C++. eine C) bspw. so 
aussieht:

1

erste.cpp  -- (avr-g++) --> erste.o  --+-- (avr-gcc o. avr.ld) --> ... erste.hex

2

                                       |

3

zweite.cpp -- (avr-g++) --> erste.o  --+

4

                                       |

5

dritte.c   -- (avr-gcc) --> dritte.o --+

, dann könnte man das so ändern, daß aus zwei Dateien eine Lib gemacht 
wird und die dann gelinkt wird:

1

erste.cpp  -- (avr-g++) --> erste.o  --+---------------------------+-- (avr-gcc o. avr.ld) --> ... erste.hex

2

                                                                   |

3

zweite.cpp -- (avr-g++) --> erste.o  --+-- (avr-ar) --> meine.lib  +

4

                                       |

5

dritte.c   -- (avr-gcc) --> dritte.o --+

Das muß man entsprechend als Regelwerk im Makefile hinterlegen, und 
fertig.

Nur als Beispiel...

Reiner Doll schrieb:
> c können die jungs schon, es ist eine prinzipielle frage, ob
> c++ mit der objektorientierung (rudimentär !) eine vereinfachung
> des programmierkonzepts für die schüler darstellt.

Können sie wirklich schon c? Richtig?

Objektorientiertes Programmieren ist eine völlig andere Welt. Um das 
richtig zu lernen braucht es Monate bei 8h täglich!
Und für kleinere µC eigentlich ziemlich unbrauchbar, da 
objektorientierte Sprachen ihre eigentliche Stärken erst mit dynamischen 
Speichermanagement auspeielen können.

Ich würde deinen Schülern eher Algorithmen und Konzepte beibringen:
Stichworte: Bootloader, Ringpuffer, interruptgesteuerte Verarbeitung, 
Zustandsautomat, ...

Reiner Doll schrieb:
> also mach ich eine .cpp als static lib project, nenn die .h, include die
> oben und  .... referenziere ?

eine .h ist kein Lib in dem Sinne.

Alles was inline ist, kann man in eine .h packen, dann hat man aber 
seitens des Linkers nichts mit Libs zu tun.

Die Geschichte mit avr-ar etc. kommt ins Spiel, wenn man mehrere *.c 
oder *.c++ kompilieren und zu einer Lib zusammenfassen will.

(Bevor ich damit auf Schüler losgehe, würde ich mir vielleicht nochmal 
klarmachen, was ein Compiler ist und was ein Linker)

Klaus Wachtler schrieb:
> Wenn der normale Weg für drei Quelltexte (zwei C++. eine C) bspw. so
> aussieht:erste.cpp  -- (avr-g++)
> --> erste.o  --+-- (avr-gcc o. avr.ld) --> ... erste.hex
>                                        |
> zweite.cpp -- (avr-g++) --> erste.o  --+
>                                        |
> dritte.c   -- (avr-gcc) --> dritte.o --+
> , dann könnte man das so ändern, daß aus zwei Dateien eine Lib gemacht
> wird und die dann gelinkt wird:erste.cpp  -- (avr-g++) --> erste.o 
--+---------------------------+-- (avr-gcc o. avr.ld) --> ... erste.hex
>                                                                    |
> zweite.cpp -- (avr-g++) --> erste.o  --+-- (avr-ar) --> meine.lib  +
>                                        |
> dritte.c   -- (avr-gcc) --> dritte.o --+

gemeint war es natürlich eher so:

1

erste.cpp  -- (avr-g++) --> erste.o  --+-- (avr-gcc o. avr-ld) --> ... erste.hex

2

                                       |

3

zweite.cpp -- (avr-g++) --> zweite.o --+

4

                                       |

5

dritte.c   -- (avr-gcc) --> dritte.o --+

, dann könnte man das so ändern, daß aus zwei Dateien eine Lib gemacht
wird und die dann gelinkt wird:

1

erste.cpp  -- (avr-g++) --> erste.o  ------------------------------+-- (avr-gcc o. avr-ld) --> ... erste.hex

2

                                                                   |

3

zweite.cpp -- (avr-g++) --> zweite.o --+-- (avr-ar) --> meine.lib  +

4

                                       |

5

dritte.c   -- (avr-gcc) --> dritte.o --+

meine lösung sieht so aus :

1) klasse (als library-projekt geschrieben und als blinker.h 
gespeichert) :

class loop
{
   //variable und so (attribut)
   public : void doblink()
   {
      // einfaches 500 ms blinken an led
   }
}

2) programm (obige .h ist im source-directory) :

#include "blinker.h"

int main (void)
{
  //..
  loop testblink;       //referenziert klasse loop
  testblink.doblink();  //methodenaufruf
}

..compiliert, in den fc übertragen : blinkt !

low level, schon klar, aber das ist eben das ziel.

Reiner Doll schrieb:
> 1) klasse (als library-projekt geschrieben und als blinker.h
> gespeichert)

Und du unterrichtest angehende Techniker in C(++)?

nein.

Re: Nein
Du unterrichtest andere Schüler oder wie soll ich das verstehen:

Reiner Doll schrieb:
> also : ich wil eine klassenbibliothek schreiben, die alle details der
> peripheriebedienung vom anwendungsprogrammierer (das sind später
> schüler) fern hält.

Reiner Doll schrieb:
> c können die jungs schon, es ist eine prinzipielle frage, ob
> c++ mit der objektorientierung (rudimentär !) eine vereinfachung
> des programmierkonzepts für die schüler darstellt.

Unabhängig davon: Wie dir ja schon geraten und erklärt wurde, solltest 
du dir erst mal klarmachen aus welchen Teilen ein C(++) Programm besteht 
und was genau passiert wenn man compiliert und linkt. Das Problem ist, 
daß heutige Programmierumgebungen das erst mal vor einem verbergen, es 
aber für das Verständnis wichtig ist.

Was ist eine .c, .cpp, .h, hpp, .lib, .dll Datei. Wofür werden sie 
gebraucht, wie entstehen sie, ...

Reiner Doll schrieb:
> meine lösung sieht so aus :
>
> 1) klasse (als library-projekt geschrieben und als blinker.h
> gespeichert)

Ähm.

In eine Header-Datei kommt die Deklaration der Klasse: Wie heißt sie, 
welche Member-Variablen und Methoden hat sie. Die eigentliche 
Implementierung befindet sich üblicherweise in einer Datei mit der 
Endung .cpp (manchmal auch .cc oder .cxx benannt).

schon klar, das gefällt euch nicht. hab ich mir schon gedacht.
aus eurer warte ist das auch mehr als verständlich.

es ging mir ja nur um bedientipps, das konzept wollte ich nicht 
diskutieren.

und ja, es geht schon um techniker, aber eben um andere themen.
und da ist die didaktische reduktion das ding. ein thema soweit 
vereinfachen, daß auch sehr schwache schüler ne chance haben, die 
struktur zu verstehen.
und weil die eben zum teil sehr schwach programmieren (da habt ihr schon 
richtig getippt), muß man "brutal" simplifizieren.

die theorie müßt ihr mir nicht erklären, ich bin dipl.ing 
datenverarbeitung,
und hab schon vor jahrzehnten compiler, linker und all das bedient, auch 
schon als systemprogrammierer gearbeitet, und, und...

das ding ist also :

es muß (wie auch immer realisiert) einen mechanisums geben, der 
komplexeren quellcode verbirgt aber die funktionen erschließt : nennen 
wirs klasse und methode

es muß dem anwender möglich sein, einfach, ohne controller know-how, auf 
dem controller z.b. einen digitalen regler zu implementieren. 
referenzieren und methoden aufrufen .. das kernproblem ist der digitale 
regler, der aus einer mechanikmodellierung heraus parametriert wird, und 
zur überprüfung der rechnung nun kurz realisiert werden soll.

...immer noch ein fall für den scheiterhaufen ?

wie auch immer : danke für eure zeit !

Wobei es auch noch zu berücksichtigen gilt, dass eine echte Lib (also 
eine Sammlung von vorcompilierten Object-Files) einen nicht ganz 
unwichtigen Nachteil auf einem AVR hat:
Die Hardwarebelegung kann in der verwendenden App nicht mehr so einfach 
geändert werden

* entweder man ermöglicht dem Compiler, beim Compilieren der kompletten
  App, den vorgefertigten Source Code erneut zu kompilieren und so
  auf die jeweiligen Hardwaregegebenheiten anzupassen
* oder man muss damit leben, dass der Code in der Lib so generisch wie
  nur möglich, und damit aber auch ziemlich ineffizient geschrieben
  sein muss.

Gerade Letzters ist aber auf einem µC in der Leistungs- und Größenklasse 
eines AVR (Mega irgendwas) ein ziemlicher Nachteil. Wenn das setzen 
eines Pin auf 1 aufgrund von softwaretechnischen Aspekten anstelle von 1 
µC-Zyklus plötzlich deren 15 benötigt, dann hat man sich dadurch eine 
nicht unwesentliche Einschränkung eingehandelt.


Und zu deiner Blink-LED:  Wie und warumn soll die Blinken? Wer treibt 
das Blinken an?
Wenn du Abstraktionsebenen auf diesem Level haben willst, kommst du 
nicht umhin, dir erst mal so etwas wie ein Basisbetriebssystem zu 
erfinden, in dem zb einen Systemtimer existiert und der alle zb 10ms in 
Form eines ISR-Aufrufs tickt. In diese ISR kann sich dann deine 
Blink-LED bei der Erzeugung einhängen, so dass sie von diesem Takt 
insofern profitieren kann, dass sie eben blinkt.

Reiner Doll schrieb:
> es muß (wie auch immer realisiert) einen mechanisums geben, der
> komplexeren quellcode verbirgt aber die funktionen erschließt

Das kann man auch in C machen. Man stellt eine Bibliothek mit fertig 
kompilierten Funktionen zur Verfügung. Der Anwender muss nur wissen, wie 
er die Funktionen aufzurufen hat und was er als Rückgabewert bekommt: 
Das kann man auch schön in die jeweilige Header-Datei hineinschreiben. 
Extrapunkte gibt es für die Verwendung von doxygen ;-)

Der Linker linkt's dann mit dem selbst geschriebenen Code zam und gut 
is.

Karl Heinz Buchegger schrieb:
> Wobei es auch noch zu berücksichtigen gilt, dass eine echte Lib (also
> eine Sammlung von vorcompilierten Object-Files) einen nicht ganz
> unwichtigen Nachteil auf einem AVR hat:

Was hier aber keine wirkliche Rolle spielt, denn es geht ja um eine ganz 
konkrete Hardware:
> Ich möchte einen ATmega1284p (der auf der Flight-Control vom
> MikroKopter)

Reiner Doll schrieb:

> es ging mir ja nur um bedientipps, das konzept wollte ich nicht
> diskutieren.

Was für Bedientips?
Du schreibst das h-File, Du schreibst das cpp File. Du fügst beides zur 
Applikation im AVR-Studio hinzu.
Noch sicherstellen, dass auch wirklich der c++ Compiler, der richtige 
Linker und die richtigen Bibliotheken benutzt werden (dazu gibt es ein 
paar Threads hier im Forum) und das wars.
Mehr braucht man auch nicht.


> und ja, es geht schon um techniker, aber eben um andere themen.
> und da ist die didaktische reduktion das ding. ein thema soweit
> vereinfachen, daß auch sehr schwache schüler ne chance haben, die
> struktur zu verstehen.

Das Problem ist, dass sie die Struktur immer noch nicht verstehen, egal 
wie stark du vereinfachst. Alles was du tust ist, du hältst den Mythos 
des "Der Computer tut was ich will" aufrecht. Das Problem: Das was sie 
schreiben ist oft nicht das was sie tatsächlich wollen. Bzw. umgekehrt.
Und das müssen sie lernen, alles andere hat auf lange Sicht keinen Sinn. 
Hältst du sie jetzt vom Wasser fern, wird das Schwimmen lernen in ein 
paar Monaten nur noch schwieriger.

Wenn du schwachen Schülern eine Chance geben willst, dann überfordere 
sie nicht mit der Aufgabenstellung. Ein Mikrocopter ist für Einsteiger 
völlig ungeeignet. Ein µC mit 32 LED an den Portpins um damit im Laufe 
von ein paar Monaten Lichtshows zu machen, ist da schon eher geeignet 
auch schwachen Schülern einige der Prinzipien klar zu machen um die es 
hier geht.

> es muß dem anwender möglich sein, einfach, ohne controller know-how, auf
> dem controller z.b. einen digitalen regler zu implementieren.
> referenzieren und methoden aufrufen .. das kernproblem ist der digitale
> regler, der aus einer mechanikmodellierung heraus parametriert wird, und
> zur überprüfung der rechnung nun kurz realisiert werden soll.
>
> ...immer noch ein fall für den scheiterhaufen ?

Ja.
Denn der Kern eines digitalen Reglers ist codetechnisch ein 5 zeiliger 
Pipifax. Da liegen erfahrungsgemäss nicht die Probleme. Die Probleme 
liegen beim Verständnis wie ein Regler arbeitet. So ist er für sie 
einfach nur eine Blackbox, anders können sie sich die Codezeilen (die du 
ihnen ja vorgeben kannst) ansehen und mit ein paar Zahlen den Code am 
Papier und Bleistift durchspielen.

Stefan Ernst schrieb:
> Karl Heinz Buchegger schrieb:
>> Wobei es auch noch zu berücksichtigen gilt, dass eine echte Lib (also
>> eine Sammlung von vorcompilierten Object-Files) einen nicht ganz
>> unwichtigen Nachteil auf einem AVR hat:
>
> Was hier aber keine wirkliche Rolle spielt, denn es geht ja um eine ganz
> konkrete Hardware:
>> Ich möchte einen ATmega1284p (der auf der Flight-Control vom
>> MikroKopter)

OK. Hatte ich nicht mehr im Kopf.

erlaube mir trotzdem den Einwand: Und was tun seine Schüler, wenn sie 
aus der Schule rauskommen und dann eine andere Hardware benutzen wollen?

wenn die mal wirklich controller programmieren müßten, würden sie wohl 
vorher von ihrer firma auf einen profikurs geschickt. das ist nicht 
aufgabe einer schule.

im konkreten fall gehts darum, das grundkonzept der mechatronischen 
vorgehensweise zu verstehen :

eine mechanik soll mit hilfe von elektronik und uc dinge könnnen, die 
sie allein nie kann.

superbeispiel (und, wohl am wichtigsten : in hohem maße motivierend ;-) 
:
ein quadrocopter.

also :

mechanik modellieren (masse, trägheit, winkelbeschleunigung, kräfte, 
momente....)

mit aktoren (motor/luftschraube) zu regelstrecke verrechnen.

regelungstechnischer ansatz (auch hier stark reduziert, weil's an 
mathematik hapert), parameter eines pid-reglers

-> realisierung (könnte man auch analog machen), um zu sehen obs passt.


(der kick ist hier nicht das zu können, der kick ist, das mit den 
gegebenen möglichkeiten hinzukriegen ! am mit gibts einen lehrstuhl, die 
machen sowas ähnliches mit supermini-mathematik ... so ähnlich wie : 
laufe einen marathon rückwärts auf einem bein ;-)

<laut gedacht>

Ganz ehrlich:
Ich denke eher, du willst deinen Ehrgeiz als Lehrer befriedigen, egal 
wie sinnlos die Sache aus lerntechnischer Sicht ist. Was dich ehrt: Das 
du dafür bereit bist einen nicht ganz unwesentlichen Teil der 
Basisarbeit zu übernehmen. (Und ich denke ernsthaft, dass du noch gar 
nicht weißt, was da konkret auf dich zukommt)

Aber ist egal. Deine Schüler werden sowieso irgendwann hier aufschlagen 
und um Hilfe rufen.

> am mit gibts einen lehrstuhl

Selten so gelacht. Nicht weil es am MIT das nicht gäbe. Sondern weil die 
dort ganz andere Voraussetzungen beim Studentenmaterial haben. Und rate 
mal: Auch am MIT hat man in den ersten Semestern erst mal die 
Grundlagenvorlesungen. Das was deine Schüler vielleicht irgendwann 
einmal als Abschlussarbeit mit viel Schweiß und noch mehr Gefluche 
hinkriegen, ist dort Grundvoraussetzung um als Student überhaupt für 
diesen Kurs zugelassen zu werden.


</laut gedacht>

nun gut, ich denke es bringt wenig das hier weiter zu diskutieren.
danke für die zeit und die engagierten antworten.

Karl Heinz Buchegger schrieb:
> erlaube mir trotzdem den Einwand: Und was tun seine Schüler, wenn sie
> aus der Schule rauskommen und dann eine andere Hardware benutzen wollen?

Für die Frage "echte Lib oder nicht" relativ irrelevant, denn das 
vorgegebene Framework kann ja so oder so nicht einfach auf eine andere 
Hardware übertragen werden. Schließlich bezieht sich "Hardware" hier ja 
eben nicht nur auf eine LED an einem Controller, sondern auf ein 
komplettes Flugobjekt. Außerdem bedeutet ja "Framework als echte Lib zur 
Verfügung stellen" nicht zwangsläufig, dass der Source-Code nicht auch 
zur Verfügung steht (für diejenigen, die tatsächlich versuchen wollen, 
es auf eine andere Hardware zu übertragen).

Also wenn man mit C++ auf AVR objektorientiert bzw. von der Hardware 
abstrahiert etwas machen will, fällt mir zuerst Arduino ein.

Macht C++, abstrahiert die Hardware,kann einfach bedient werden, und es 
gibt eine Unmenge Hardware Varianten (Clones...).

Ich sehe im Grunde genommen zwei Möglichkeiten:

1.) Eine komplexere Aufgabe wählen, "weil sie halt schön ist" 
(Quadrocopter). Dann muss man die Komplexität so weit reduzieren, dass 
es mit den gegebenen Vorkenntnissen und den zur Verfügung stehenden 
Mitteln (Zeit, Budget) machbar ist.

2.) Eine einfachere Aufgabe wählen, z.B. einen Roboter à la ASURO, 
NIBObee o.a. zusammenbauen und programmieren ("folge der schwarzen Linie 
am Boden bis zum Bierkasten" :)

Stefan Ernst schrieb:
> Karl Heinz Buchegger schrieb:
>> erlaube mir trotzdem den Einwand: Und was tun seine Schüler, wenn sie
>> aus der Schule rauskommen und dann eine andere Hardware benutzen wollen?
>
> Für die Frage "echte Lib oder nicht" relativ irrelevant, denn das
> vorgegebene Framework kann ja so oder so nicht einfach auf eine andere
> Hardware übertragen werden. Schließlich bezieht sich "Hardware" hier ja
> eben nicht nur auf eine LED an einem Controller, sondern auf ein
> komplettes Flugobjekt. Außerdem bedeutet ja "Framework als echte Lib zur
> Verfügung stellen" nicht zwangsläufig, dass der Source-Code nicht auch
> zur Verfügung steht (für diejenigen, die tatsächlich versuchen wollen,
> es auf eine andere Hardware zu übertragen).


Ich hab das allerdings eher so gedacht, dass die Schüler zumindest 
Programmkonzepte mitnehmen.

So wie das momentan im Raum steht, sieht das Programm, überspitzt 
ausgedrückt, so aus:

1

int main()

2

{

3

  FlighController control;

4

5

  control.Pu = 100;

6

  control.Pi =  50;

7

  control.Pd =  20;

8

9

  control.SetTimeStep( 100 );  // Milliseconds

10

11

  while( 1 )

12

    control.work();

13

}

Das ist natürlich legitim, wenn man praxisbezogen die Parametrierung 
eines PID Reglers demonstrieren kann bzw. Parameterrechnung durchgehen 
will.

Aber wozu brauch ich da C++? Wozu brauch ich da eine echte Lib?
Alles was die Schüler tun, ist die Konstanten zu verändern. Von allem 
anderen halte  ich sie fern. Und zwar auf einer Ebene, die mir 
persönlich ehrlich gesagt schon zu weit von der µC-Ebene entfernt ist.
Wenn ich das tun will, dann geb ich ihnen einfach den fertigen Code und 
sag ihnen welcher Wert im Programm welchem in der Vorlesung entspricht. 
Ob der dann C oder C++ (oder BASCOM oder Assembler oder Pascal) ist, 
spielt keine Rolle.

Gelernt haben sie dabei (abgesehen von der PID Paramterierung) nichts.

Reiner Doll schrieb:
> die theorie müßt ihr mir nicht erklären, ich bin dipl.ing
> datenverarbeitung,
> und hab schon vor jahrzehnten compiler, linker und all das bedient, auch
> schon als systemprogrammierer gearbeitet, und, und...

Dann solltest Du doch aber wissen, wie man eine Lib erstellt.
Ob sie nun .dll oder .a heißt, sind pure Nebensächlichkeiten.


Peter

hallo helmut,

hätte dich gerne per pn oder mail erreicht, aber der link ist nicht 
aktiv.

ich möchte das pädagogische konzept hier nicht diskutieren (ist ja 
schließlich ein technisches forum..), aber dein (FH) hat mich hellhörig 
gemacht. (FH München ?)

ein kernziel ist, auszutesten (projektarbeiten), ob unsere schüler mit 
dem uc als werkzeug für mechatronische systementwicklung ohne (!) 
spezielle fachbegleitung zurechtkommen können. doku gibts ja zuhauf im 
web.

weil die avr-familie und c/c++ bei uns etabliert sind (wenn auch in 
anderen fachbereichen), habe ich diese ausgewählt. der quadrocopter 
natürlich wegen der motivation (nahezu intrinsisch, jedenfalls bei mir 
;-), die fertige mikrokopterhardware, weil wir kein hw-labor (löten 
usw.) mehr haben.

SEHR interessiert bin ich an der luna - geschichte. für diesen guten 
tipp ertrage ich auch gerne das "du-bist-ein-mieser-lehrer" - bashing 
hier ;-)

wie sind eure erfahrungen ?

z.b. die bedienung der seriellen schnittstelle oder die timer sind in c 
schon ganz schön kryptisch, ich krieg das schon hin, aber für die 
schüler ist das nix (deshalb die idee mit der "kapselung") .  .... wird 
das besser in luna ?

Reiner Doll schrieb:
> (deshalb die idee mit der "kapselung")

Kapselung hat nichts mit einer Lib oder C/C++ zu tun.

Du hast erstmal die Source-Ebene.
Da kannst Du C, C++ oder gemixt verwenden.

Dann kannst Du Sourcen (*.c, *.cpp) vordefinieren und als Lib 
bezeichnen. Die müssen dann im Makefile mit compiliert werden.
Der Vorteil ist, sie können noch durch *.h Files gesteuert werden, z.B. 
andere Pinbelegung, Quarzfrequenz usw.

Dann kannst Du diese Libs vorcompilieren (*.obj). Die kann dann jemand 
hinzulinken, ohne sie verstehen zu müssen. Sie müssen auch nicht mehr 
als Sourcetext (lesbar) vorliegen. Damit hast Du schon Deine "Kapselung" 
vor neugierigen Einblicken.
Pinbelegung usw. sind dann festgelegt.

Dann kannst Du die Lib-Objekte zu einer Lib (*.a) zusammen fassen 
lassen. Der Unterschied ist dann, daß der Linker nicht die komplette Lib 
linkt, sondern nur die benötigten Objekte.
Man muß also nicht mehr den Linker anweisen, daß er toten Code wieder 
entfernt (ginge aber auch).

Und auf dem PC hast Du dann noch als weitere Stufe, daraus eine DLL zu 
erzeugen, die erst zur Laufzeit nachgeladen wird. Aber das ist wirklich 
nur das I-Tüpfelchen, der ganze Rest ist genau gleich.
Auf einem MC wäre das Nachladen in den Flash recht sinnfrei (von woher 
denn?) und auch langwierig.


Peter

Helmut schrieb:
> Grundsätzlich ist C/C++ immer die richtige Wahl.

Na, na ;-)

Man kann zwar mit diesen beiden Sprachen alles machen - aber häufig 
Strings parsen oder Web-Anwendungen etc. will man damit ja nicht 
wirklich.

@peda : dir sind die "..." entgangen.

@helmut : nach erstem eindruck ist luna sehr, sehr gut für meine 
zielgruppe.
mechatroniker ("mecha" !) haben zwar softwareentwicklung als fach 
(objektorientierung usw.) , sind aber trotzdem schwache programmierer.
ich spare mir den klassenbibliotheks-aufwand, trotzdem ist der 
sourcecode ungemein übersichtlich und gut strukturierbar.
wenn alles glatt läuft, wirds dann nächstes schuljahr einen prüfstand 
(eine achse eines copters mit ner webcam) geben, der, aus dem web 
steuerbar, jedem user die möglichkeit gibt selber regelalgorithmen und 
filter zu programmieren, und dann online auszuprobieren.

erfahrungsaustausch wäre wünschenswert ...

Hallo Reiner,

habe mit Interesse deine Beweggründe für C++ hier gelesen und kann dir 
in vielem nur zustimmen... als Schüler/Einsteiger wie mir ist C++ gar 
nicht so übel wenn man gleich damit anfängt. Übel ist der Wechsel im 
Kopf wenn man erst mal mit C oder ASM angefangen hat und diese Denke 
verinnerlicht hat und dann umsteigen will. Die Sprache mit du man 
anfängst ist sozusagen deine muttersprache jede weitere eher eine 
fremdsprache. Wie sehr die mentalen Hürden wirken sieht man hier in den 
Foren an den teilweise extrem emotionalen reaktionen gegen die 
Objektorientierung... ich hab einen Tipp für dich:

www.avr-cpp.de

bin noch nicht ganz mit dem Tutorial durch aber bisher hat es mir sehr 
geholfen :)

Gruß Jahat

ja mag schon sein dass ich nur das nachplappere was ich gelesen oder 
gehört habe **schäm** aber in einem musst mir recht geben manchmal wird 
C++ hier gerade zu verteufelt :/ ... wie auch immer ich komm mit 
objektorientierten programmen besser klar als mir alle dem anderem und 
denk schon dass es daran liegt dass wir zuerst mit java angefangen haben 
...

gruß Jahat

Nur ist es leider so, daß man sich genau die Denkweise, die das OOP 
ausmacht, auf einem kleinen Controller weitgehend abschminken kann.

Man kann vieles von C++ nutzen, aber eben lange nicht alles. Und was man 
sinnvollerweise darf und was nicht, weiß man genau dann, wenn man es in 
C statt in C++ auch machen könnte.

Insofern hilft OOP auf einem AVR o.ä. für Anfänger genau gar nichts - 
die wissen nämlich nicht, was sie eigentlich tun und treiben noch mehr 
Unfug als mit einer übersichtlichen Sprache, die weitgehend 1:1 in 
Maschinensprache übersetzt werden kann.

Ich bin der letzte, der C++ verteufelt - ganz im Gegenteil.
Aber hier darf man nicht nur die schöne Fassade sehen, sondern muß in 
etwa wissen, was dahinter abgeht.

(Fürchte den Bock von vorn, das Pferd von hinten und das Weib von allen 
Seiten. So ähnlich ist C++ auf einem Controller...)

Das ändert aber nichts daran, daß auch ein Anfänger (darum geht hier 
m.W.) den Ablauf hinter der Fassade nicht lange ignorieren kann und sich 
damit letztlich noch mehr Komplexität auf einen Schlag anlacht als 
ohnehin schon.

Ich bin ganz bestimmt für OO, aber nicht dafür NUR die schöne Fassade zu 
sehen, ohne Ahnung was man dahinter anrichtet.
Bei größeren Rechnern kann man das Dahinter länger ignorieren (zumindest 
versuchen es viele), aber auf einem kleinen Controller sicher nicht.

Wo irgend möglich, macht es aber Sinn, anfangs die Komplexität soweit 
wie möglich zu drücken.
Deshalb halte ich nicht viel davon, auf einem Controller mit C++ und OO 
anzufangen. Ausnahme natürlich dann, wenn ein Einsteiger mit einer 
wohldurchdachten Klassenbibliothek anfangen darf - das kann ihm den 
Einstieg erleichtern. Eine solche halbwegs allgemeingültig zu schaffen, 
ist aber nicht trivial.

Mark Brandis schrieb:
> Man kann zwar mit diesen beiden Sprachen alles machen - aber häufig
>
> Strings parsen oder Web-Anwendungen etc. will man damit ja nicht
>
> wirklich.

Hallo Mark,

das würde ich nicht so unterschreiben.

Wenn ich zB. nur ein paar Daten von einer Webseite benötige nehm ich
c(++), einen Socket und sag dem Server, das ich nur Text verstehe und er 
den ganzen Flash und Multi-Dingbums-Krempel für sich behalten soll. Die 
Info, die ich will ist dann schnell aus dem HTML Quelltext gefiltert.

Und auch umgekehrt. Ein Embedded Webserver schickt zu 95% immer den 
gleichen HTML-Text nur mit ein paar Variablen Stellen darin.

Warum sollte ich da Apache und PHP bemühen ;)

Keine neue Frage, nur "Stand der Dinge"... :

Mit Luna (nochmal Danke für den Tipp) hats schließlich im Vorlauf sofort 
funktioniert. Das Ding fliegt, und bietet Projektaufgaben ohne Ende.
Achsregler sind fertig, jetzt kommt Höhe und Gier, dann GPS.

(Obwohl ehrlich gesagt : Die erste Gruppe hats dann doch in C 
geschrieben ;-)

Wers nicht glaubt : http://www.youtube.com/watch?v=glPcMwdeHVY 
(schwingt prima wegen zu hohem P-Anteil ;-)

Wichtig : alles ohne höhere Mathematik, also keine z-Transformation oder 
solche Späße, auch alles nur mit kartesischen, reelen Koordinaten. Sonst 
versteht das hier keiner ...

Nächste Schritte :
http://portal.ts-muenchen.de/index.php?option=com_content&view=article&id=45&Itemid=40


---> Irgendwer auf ähnlichem Weg ???

Mir hat das Ding zu viele Restriktionen:

- geschlossener Code
- unbrauchbarer Chip nach Bootloader-Tausch
- keine Einzelbauteile für leistungsfähige ESCs
- veraltete Analogbauteile (+ Overhead)
- Reichweitenbegrenzung
- viel zu teuer in ALLEN Komponenten

Ich hab zwei Arducopter-Steuerungen, sie nutzen den zweiten darauf 
befindlichen Atmega als Fail-Safe, alles ist offen, preiswerter (fast 
nur halb so teuer!), du kannst jeden beliebigen Chinesen-Regler 
verwenden, und die Entwickler-Community ist viel größer und 
professioneller (als die fast ausschließlich deutsche). Seitdem bin ich 
von LUFA (Datenverkehr über USB) begeistert. Und ich wette mit dir: Ein 
Argument die ATMegas für die GPS-Auswertung zu verlassen war ihr 
erweiterter Produktschutz (übrigens: der 2560 des Ardu macht das sogar 
noch nebenbei...)

Bei den Mikrokopter-Cronies bekommst du zB am WE keine Email-Antwort, 
die mchen das nur zu deren "Öffnungszeiten" unter der Woche. Auf so 
einem hohen Roß sitzen die. Es steht wohl das Geldverdienen und 
Vermarkten im Vordergrund und nicht der Spaß an der Elektronik.