Druckbare Version
nachdme bem asuro ein c++ compiler verwendet wird, frage ich mich, warum wird der asuro eigentlich immer nur in c programmiert und nicht in c++
c++ hätte diverse vorteile (objektorientierung d.h klassen vererbung etc)
liegt das einfach nur daran, das c leichter ist, als c++, oder gibt es da einen technischen hintergrund, den ich nihct kenne?
mfg EDH
Gerade unter diesem Aspekt ist auch Vererbung nicht so lecker, zumindest dann, wenn man abstrakte Klassen will, Thema VTables.Zitat:
"When programming C++ in space- and runtime-sensitive environments like microcontrollers, extra care should be taken to avoid unwanted side effects of the C++ calling conventions like implied copy constructors that could be called upon function invocation etc. These things could easily add up into a considerable amount of time and program memory wasted. Thus, casual inspection of the generated assembler code (using the -S compiler option) seems to be warranted."
Zudem gibt es keine volle C++ Unterstützung (Exceptions, new, delete, libstd++, etc).
Und ob man wirklich ein objektorientiertes
ATmega8.portC.bit3.set();
will, wage ich auch zu bezweifeln...
Mir persönlich ist C++ zu intransparent. Bei dem, was man alles beachten muss damit Code und Laufzeit nicht explodieren und den Einschränkungen ist man IMHO wesentlich besser mit C bedient.
naja c++ is ja schön und gut, aber wenn ich mich nicht irre kann man mit c einzellne bits ansteuern, was für einen roboter ziemlich praktisch ist. bei c++ kann man keine einzellnen bits ansteuern, deshalb ist c für den asuro besser.
falls ich mich irre bitte ich das zu entschuldigen
mfg toschtosch
du kannst den asuro in c++ proggen, du kannst den asuro mit bascom proggen, du kannst den asuro mit java proggen, du kannst den asuro mit fastavr proggen, du kannst den asuro mit microbasic for avr proggen, du kannst den....
@tosch'
also warum sollt ein C++ kein Befehl gemantelt sein, der auch Bitweise zugreifen kann ...
.. also C++ ist in meinen Augen ein Mantel, der viele C-Funktionen abstrahiert.
Das verursacht einen Overlay, der im begrenzen Speicherreich des uC mehr als unnötig ist.
Frag einen asm-king, warum er keine Hochsprache nutzt - das gibt sehr effizienten Code ... vorausgesetzt, der Programmierer hat Ahnung und Erfahrung .. in C ist es ähnlich, eben eine Stufe abstrakter ... C++ wäre eben oversized .....
Wenn Atmel einen mega mit 1GB/1GHz hätte, würde dies sicher verwendet werden ... aber ein asm-Profi wäre da immer noch im Vorteil :-)
"Oh mein Programmiergott, dann gäbe es sicher auch einen Basicinterpreter"
.. sorry, daß mußte sein
Naja, ganz so schlimm ist es ja nun nicht...
wenn ich mich recht erinnere war ein Grundsatz bei C++,
daß nicht verwendete Features auch keinen zusätzlichen Ballast erzeugen sollten.
Man sollte also, wenn man Dinge wie abstrakte Klassen o.ä. nicht benutzt,
mit C++ fast genauso effiziente Programme schreiben können wie mit C.
Aber warum C++ wenn man die besten Sprachkonstrukte nicht benutzen sollte?
Naja, selbst wenn man die für Mikrocontroller ungeeigneten Features nicht nutzt,
kann das was von C++ noch übrig ist immernoch Vorteile gegenüber C haben.
Objektorientierte Programmierung ist ja z.B. immernoch möglich,
wenn auch nur in ihrer einfachsten Form.
Gruß,
Felix
PS: @1GB/1GHz ... schau dir doch mal einen ARM9 an, die dürften da deutlich drunter liegen.
(und in den meisten Fällen laufen auf den Dingern Betriebssysteme wie Windows CE oder Linux)
also der klare nachteil an c++ ist wie schon oben genannt dass man eine funktion in c++ meist auf viele funktionen in c zurückführen kann. deshalb kann es gut und schnell sein dass die 7k des asuro plötzlich knapp werden.
selbstverständlich ist es möglich, auch in c++ knappen, guten code zu schreiben, aber was spricht denn gegen c?
such mal nach
da sind viele alternativen zu c zu finden... ich persönlich versuche mich gerade an bascom. aber auch das java würde mich mal interessieren...Zitat:
du kannst den asuro in c++ proggen, du kannst den asuro mit bascom proggen, du kannst den asuro mit java proggen, du kannst den asuro mit fastavr proggen, du kannst den asuro mit microbasic for avr proggen, du kannst den....
java wäre aber genauso wie c++ objektorientiert. gäbe es dann nicht auch wieder diesen unnötigen balast?
an sich schon... wobei das hauptproblem an java wäre dass eine minimal- java-vm im prozessor (!) laufen müsste. es gibt sogar schon eine für den asuro (http://www.mikrocontroller.net/articles/NanoVM), die jedoch beinahe den gesamten flash braucht.
darum würde ich java eher als spielerei als als alternative sehen =)
Also Java ist definitiv viel schlimmer als C++, da es eben nur interpretiert wird.
(ein C++ Programm wird vom Compiler in richtigen Maschinencode übersetzt)
Interpretersprachen machen auf einem solchen Mikrocontroller nicht wirklich viel Sinn.
(dazu würde eigentlich auch Basic zählen, aber Bascom ist hier eine Ausnahme da es ein Compiler ist)
In java gibt es noch den zusätzlichen Ballast, dass alles in ein JRE gepackt wird, dass nochmal Speicher verbraucht.
new/delete sehe ich nicht als großes Problem, da man das ohne großen Aufwand über malloc/free nachbilden kann. Exceptions sind für mich auch ohne Belang. Ich benutze ja auch kein setjmp/longjmp (die Entsprechung in C)- OK na gut, ein-, zweimal in 17 Jahren C Programmierung habe ich es schon benutzt.
Und was Vererbung und Polymorphie angeht: Da sind die vtables der Preis den man zahlen muss (der nicht sehr hoch ist).
Was Code und Laufzeitexplosion angeht stimme ich Sprinter zu. Da sollte man schon wissen, was man tut. Das gilt für C zwar genau so, aber bei C++ (und ebenso bei Java) sind da einige Dinge mehr zu beachten.
Der größte Nachteil ist im Moment, dass der Debugger/Simulator im WinAVR nicht mit C++ Code zurecht kommt. De facto der einzige Grund, der mich vom Wechsel zu C++ abhält.
Wenn du deinem Java-Compiler sagst, daß er ausführbaren Code machen soll, wird er das gerne für dich tun. Wo steht geschrieben, daß Java nur auf einer VM laufen darf?Zitat:
Zitat von Felix G
Versuch mal ein gcj (GNU compiler for java, just a flavour of GCC) aus. Etwas schade ist, daß nur bis Java 1.3 unterstützt wird (zumindest was die libjava angeht). Andererseits... wenn man im Sinn hat swing zu benutzen, wird es bestimmt nicht auf einem AVR sein...
Wie gesagt, daß ist natürlich kein Thema. Ich hab das einst mal ausgetextet.Zitat:
Zitat von vajk
Macht einfach mal folgendes Jungs: Schreibt euch Klassen, die schön euren µC abstrahieren. Z.B. ein Port-Klasse, die es euch erlaubt, ein Port-Bit als In oder Out zu setzen, als HIGH oder als LOW oder zu togglen. Dann schaut euch den Code an und wir sprechen uns wieder. Entweder macht man die Methoden static inline und kann nicht ableiten, oder man kommt zu super breitem, nicht-atomarem Code. ...ok, wir können unser Port-Setzen ja atomisieren, aber dann haben solch simplen Aktionen schon empfindliche Auswirkungen auf die IRQ-Latenz.
BTW, indem man so unterwegs ist nun schön seine ATmega8-Klasse implementiert und verwendet, *verliert* man Portierbarkeit!
Im Endeffekt textet man dann die Features mit C-Code nach, proggt an der Objektorientierung vorbei, etc.
Bei welchem Beispiel bringt C++ Vorteile wie portierbareren, schnelleren, transparenteren oder schlankeren Code?
Also meines wissens... in keinem =/
und java... nunja, man kann es kompilieren, muss man aber nicht =)
wenn man will, kann man auch das ganze ding in Brainf..k programmieren (eine Programmiersprache, die nur aus den zeichenbesteht, siehe http://de.wikipedia.org/wiki/Brainfuck), die frage ist einfach ob das sinn macht. wer langeweile hat kann auch selbst eine programmiersprache entwerfen, einen entsprechenden compiler dazu schreiben und diese verwenden.Code:[]+-,.<>
aber warum sollte man das tun? c reicht doch völlig aus... und wer gern bascom, java oder c++ benutzen will, der soll das doch tun =) wenn eine programmiersprache so viele nachteile hätte, dass diese gegenüber den vorteilen überwiegen (was jeder für sich selbst entscheiden muss) dann benutzt man sie halt nicht. aber das muss jeder für sich überlegen...
aber der erste, der es schafft nur mithilfe von brainf..k die frontled zum leuchten zu bringen, der bekommt nen kasten bier =)
So schlecht finde ich das Brainfuck garnicht mal. Schön übersichtlich, im Gegensatz zu INTERCAL (--> http://de.wikipedia.org/wiki/INTERCAL) wo es so schöne Befehle wie ComeFrom gibt, das Inverses [sic!] zu goto!
Für Brainfuck wäre noch die Semantik von getchar und putchar zu klären. Gehen die auf's RAM? Ist wohl das sinnvollste, den RAM als Band herzunehemen.
ich würde mal spontan sagen dass das vom compiler abhängt, oder nicht?
also im standart-compiler den man des öfteren findet geht es nach stdin und stdout, also keyboard un bildschirm.
ich habe es mal irgendwann geschafft, in INTERCAL ein Programm zu schreiben, das HELLO WORLD in zwei zeilen untereinander ausgibt. dann hab ich es gelassen =)
also ComeFrom ist wirklich einer der härtesten befehle überhaupt... o0 man muss sich einfach drauf verlassen, dass der prozessor bzw interpreter genau an dieser stelle, die mittem im programmcode liegen kann, die unterroutine ausführt... daran kann man sich ncih gewöhnen =)
Falls jemand noch nach Sprachen sucht:
http://www.ntecs.de/old-hp/uu9r/lang/html/lang.de.html
programmiersprahcne gibt es schon sehr viele. aber ich schätze bei den meisten ist es genauso wie bei den ungefähr 15 000 kleinen linux distributionen.
sie werden einfach aus spaß an der sache entweickelt. was für einen praktischen nutzen (auser die gehirnzellen zu trainiern) hat eine programmiersprache die nur aus [ ] + - , . < > besteht?
das nimmt in der praxis warscheinlich niemand her
da könntest du recht haben =)
wobei: diese programmiersprache ist SEHR nach an einer Turingmaschine empfunden, und das ist auch was schönes =) also könnte man evtl, anstelle eines kompilers, einen mega8 und ein lochkartenlesegerät mit einem lcd und keyboard koppeln und dann anstatt zu programmeiren, einfach lochen =)
dann sind wir wieder zurückversetzt... aber ob das sinn macht...
=)
es gibt auch eine programmiersprache, die als quellcode ein bitmap will (http://de.wikipedia.org/wiki/Piet). daran könnte man sich mal versuchen...