Hallo liebe Profis,
jetzt mal langsam bitte.
Ich möchte einen ATmega1284p (der auf der Flight-Control vom
MikroKopter)
objektorientiert selber bespaßen. Das Ganze auf AVR Studio.
In Vb .net kann ich sowas, aber hier in C++ für Controller hackts.
simples Beispiel sei :
Ich möchte eine Klasse schreiben, die als einzige Methode einen Zähler
beinhaltet.
Nun möchte ich ein Programm haben, das diese Klasse referenziert, die
Methode aufruft und fertig.
.. Wie schreib ich die Klasse in AVR ?
.. Wie binde ich sie ans Programm ("Verweis" ??) an ?
.. wie referenziere ich ?
blöde Frage ? sorry ...
Die Sprache ist C++ nicht AVR.
Sinnvoll wäre es, sich ein C++-Buch oder Tutorial zu besorgen und C++ am
besten am PC zu üben, da die Debugmöglichkeiten besser sind.
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 ??
Reiner Doll schrieb:> in vb2010 (auch auf visual studio) muß man die selber erzeugten> klassen im projektordner als verweis (.dll) einfügen.
nein muss man nicht, warum sollte man jede klasse als DLL bauen?
Man verwendet DLL nur als Sammlung von Klassen die man in verschienden
Projekten verwenden möchte.
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 ??
es ist erstmal ein ganz normales C/C++ compiler - auch die verwendung
ist gleich.
Also fang erstmal auf dem PC an dir eine lib zu bauen.
Aber ich würde von C++ abstand nehmen, es gibt doch einige
einschränkungen (kein NEW, keine STL).
Warum nicht erstmal mit C anfangen?
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 ?
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.
Wenn die Schüler bereits C programmieren, würde ich eine Bibliothek aus
gut dokumentierten Funktionen aufbauen.
So können die Nichtso-sehr-Interessierten die Funktion einfach verwenden
während sich Interessierte sogar den Quellcode der Funktion anschauen
können.
Außerdem spart man den Schülern das Umdenken zur Objektorientierung hin.
Grad da tun sich die Schüler sehr schwer, vor allem, wenn man die beiden
Denkweisen mischt.
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:
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:
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.
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:> low level, schon klar, aber das ist eben das ziel.
Warum sollte man den Blinkcode verstecken wollen anstatt ihn direkt
hinzuschreiben?
Wenn du wirklich derart programmieren möchtest, wäre vielleicht Bascom
was für dich?
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>
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" :)
Warum eigentlich die armen z.T. "lernschwachen" Schüler auch noch mit
C++ Klassengedöns maltretieren? Was noch dazu auf AVR bezogen nicht so
der Renner zu sein scheint (milde ausgedrückt; kurz recherchiert). Es
klingt doch eher an, dass es hauptsächlich um das Angehen einer
Mechatronischen Aufgabenstellung geht und nicht darum jetzt auch noch
OOP zu lernen oder?
Vielleicht wäre da luna was für dich
http://avr.myluna.de/doku.php?id=de:class-endclass
erlaubt auch Klassen, ist aber ansonsten (so mein Eindruck) recht
schnell zu begreifen und damit Einsteigertauglich.
Ich weiß nicht was die anderen die mehr Erfahrung diesbezüglich haben
darüber denken, ob das was für dein Anliegen wäre. Ich stelle es halt
mal in den Raum.
Beispiele mal anschauen
http://avr.myluna.de/doku.php?id=de:beispiel-sourcen
Wie sich das mit der Performance bei luna verhält (im Vergleich zu C)
weiß ich allerdings momentan nicht.
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
intmain()
2
{
3
FlighControllercontrol;
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
> Beispiele mal anschauen> http://avr.myluna.de/doku.php?id=de:beispiel-sourcen>> Wie sich das mit der Performance bei luna verhält (im Vergleich zu C)> weiß ich allerdings momentan nicht.
Wir prüfen gerade dies als Vorstufe und Einstieg einzuführen (FH), vor
allem weil der Entwickler hier aufgeschlossen ist und es den Studenten
die Chance bietet direkt an der Sprache mitzuwirken. Die Geschwindigkeit
bewegt sich im C-Bereich.
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
Hallo Reiner,
FH Münster, ich melde mich die Tage mal per Mail, nur soviel vorab:
Grundsätzlich ist C/C++ immer die richtige Wahl. Ausbildungsbereiche bei
denen die Programmierung selbst einen weniger hohen Stellenwert einnimmt
und der Fokus mehr auf der Hardware und Systemprozesse liegt, kann das
aber auch nach hinten losgehen (ich denke da z.Bsp. auch an die
Fachinformatiker). Hier ist z.T. nicht genügend Zeit die Grundlagen zu
vermitteln.
Viele der Schüler und Studenten bringen bereits eigene Erfahrungen mit
Visual Basic, Real Studio oder Delphi mit. Bascom als direkter
Basic-Dialekt kommt jedoch nicht für uns in Frage. Luna ist uns hier
aufgefallen, da es trotz seines scheinbar jungen Entwicklungsstands
schon zum jetzigen Zeitpunkt sprachlich und funktionell mächtiger und
dem C/C++ näher steht als Bascom, zudem fallen keine Lizenzkosten an
(!). Auch ließen sich Testprojekte bisher recht einfach von C nach luna
portieren. Nicht zu verschweigen sind hierbei einige Defizite und
semantische Inkontinuität von luna, die wohl dem jungen
Entwicklungsstand zuzurechnen sind. Positiv ist zu bewerten, dass
Einfluss auf die Sprache selbst genommen werden kann. Ich empfehle den
Kontakt mit dem Entwickler.
Gruß aus Potsdam (derzeit),
Helmut
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
Jahat Iblis schrieb:> als Schüler/Einsteiger wie mir ist C++ gar nicht so übel wenn man gleich damit
anfängt.
Solche Argumente hoert man von Einsteigern oft, aber mit Verlaub - wie
will ein Einsteiger das beurteilen koennen? Nur, weil es scheinbar
leichter faellt, ist es nicht auch besser.
> Ü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.
Gerade der Uebergang von Assembler zu C und dann zu C++ ist sehr
fliessend. Allerdings nur, wenn man sich nicht von irgendwelchen Dogmen
und Paradigmen geisseln laesst und sich selbst auch entwickelt. Denn
dann ist C zuerst einmal nur das maechtigere Assembler und C++ ist zu
Beginn nur die Erweiterung von C, mit der man seine modularen Konzepte
leichter umsetzen kann.
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...)
jetzt muss ich mich hier auch mal rein hängen ... die argumentationen
gegen objektorientierung waren schon vor zwanzig jahren genau die selben
und trotzdem hat es sich durchgesetzt und setzt sich weiter durch auch
auf Controllern ... vielleicht nicht unbeding auf 8bitern aber ich hab
mir diese seite von jahar mal angeschaut und siehe da es sieht doch gar
nicht mal so übel aus... und was die schöne fassade angeblangt und das
argument dass man doch wissen muss was intern so läuft und wie die bits
poltern... naja ich möchte hier keinen glaubenskrieg lostreten aber das
ist kein argument gegen objektorientierung sondern eines dafür und
entspricht derem grundkonzept der abstraktion... und die
gegenüberstellung hier find ich wikrlich genial
1
// offizieller AVR C Standard ///////////////////////////////////////
2
if(!(PIND&(1<<PD2)))
3
PORTB&=~(1<<PB7);
4
5
// das Gleiche mit myAVR C++ ////////////////////////////////////////
6
if(pinD.bit2==0)
7
portB.bit7=0;
8
9
// und mit Klassen aus dem myAVR C++ Framework //////////////////////
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.
Für mich ist ein wesentlicher Schlüssel zu gutem Code das modulare
Programmieren mit strikter Kapselung der Daten.
C++ ist für mich eine konsequente Weiterentwicklung in diese Richtung:
mit Klassen läßt sich noch besser kapseln.
Daher programmiere ich auch AVRs in C++. Wenn man C++ richtig anwendet,
ergibt sich kein Nachteil bzgl. Laufzeit und Codegröße, dafür der
Vorteil, daß der Compiler einem Kapselungsarbeit abnimmt und Verstöße
strenger ahndet.
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 ;)
Ich versuche mal kurz eine eigene Zusammenfassung (wie es auf mich
wirkt). Auch, wenn das Konzept gar nicht gefragt war:
Lernende mit sehr wenig Programmierkenntnissen sollen etwas
Programmieren. Das Programmieren ist aber nur Beiwerk einer komplexeren
(eigentlich mechanisch orientierten) Gesamtaufgabe. Aus
Motivationsgründen wird ein interessantes "Objekt" gwählt, wo man die
Änderungen (Hard- und Softwarekomponenten) gut dran erkennen kann. Der
Softwareteil soll aber auf eine ultrasimple Bedienerschnittstelle
reduziert werden.
Also ich würde es spontan so ähnlich machen, wie Karl Heinz es
vorgeschlagen hat: "Normales" Programmieren der gewünschten Funktionen
auf "handelsüblicher Standardhardware". Dazu die Stellen markieren, wo
die relevanten Stellen im Code sind. Variablen, Reglerberechnung etc.
Schön modular, Einführung mit Flußdiagramm usw.. Wer will, kann gerne
tiefer in das Programm einsteigen ("Leistungskurs?"). Wer nicht, der
eben nicht. Gleiches könnte man auch für die anderen Komponenten des
"Objekts" machen (Sensoren, Motoren etc.). Vielleicht auch gleich
Schwerpunktgruppen bilden und später tragen alle alles zusammen (wobei
mir das damals ziemlich widerstrebt hat. Ich hätte mich lieber mehr mit
dem beschäftigt, was mich am meisten interessiert).
Das reicht dann aber auch wirklich; soll ja auch zeitlich umseztzbar
sein.
Auch wenn C nicht mehr der Standard ist, der er mal war, so kann man als
absoluter Anfänger doch die allersimpelsten Programmstrukturen daran
lernen. OO ist sicher eine ganz andere Denke, aber m.M. nach wird,
gerade im Mechatronikbereich, noch so manches Jahr Hardware effektiv in
C programmiert werden. Andere Software wohl eher nicht mehr.
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.
Thread beobachten
Seitenaufteilung abschalten