Verwirrung in Programiersprachen!Wer schaft mir Klartext?
-
Tim schrieb:
fricky schrieb:
leider sind die embedded-gcc's nicht annähernd so gut, wie die für die grossen systeme.
Du hast sie ja alle schon getestet, gelle?
den für arm, v850 und s12 habe ich getestet. alle wurden von kommerziellen compilern arm/iar, v850/greenhills s12/codewarrior in bezug auf schnellen und schlanken code, gandenlos abgehängt. und zwar *alle*. das lässt mich darauf schliessen, dass auch andere gccs, bis vielleicht auf die für x86, nicht so toll optimieren können.
-
jo, ich hab schon projekte gesehen, wo man im C++ -abstraktionswahn µC-projekte angefangen hat
In der µC-Programmierung wird man vermutlich den gleichen Weg gehen wie bei den PCs, nämlich von ASM über C zu OOP-Sprachen wie C++ oder Java. Warum auch nicht? Zumindest bei größeren Programmen. Momentan ist das aber vorwiegend gekapseltes C, new und delete fehlen noch, und so weiter.
Die derzeitgen Speichergrößen (SRAM von wenigen KByte) sind für OOP noch nicht ausgelegt. Das ist aber nur eine Frage der Zeit. In wenigen Jahren wird man nicht mehr verstehen, warum man bei µC mit ASM gearbeitet hat.
-
Erhard Henkes schrieb:
jo, ich hab schon projekte gesehen, wo man im C++ -abstraktionswahn µC-projekte angefangen hat
In der µC-Programmierung wird man vermutlich den gleichen Weg gehen wie bei den PCs, nämlich von ASM über C zu OOP-Sprachen wie C++ oder Java.
http://www.harbaum.org/till/nanovm/index.shtml
Erhard Henkes schrieb:
Die derzeitgen Speichergrößen (SRAM von wenigen KByte) sind für OOP noch nicht ausgelegt. Das ist aber nur eine Frage der Zeit. In wenigen Jahren wird man nicht mehr verstehen, warum man bei µC mit ASM gearbeitet hat.
µCs werden meistens in grossen stückzahlen verkauft und solange die kleinen chips billiger sind als grosse, und wenn es nur wenige cent sind, werden sie nicht aussterben.
-
sothis_ schrieb:
ich meine es sollte durchaus alternativen zu C und assembler im embedded bereich geben, das kann nicht schaden. aber objektorientierung hat im lowlevel sektor, gar nichts, aber auch rein gar nichts verloren, zumindest nicht auf heutigen prozessorarchitekturen
Wieso nicht? Wenn man OO-Problemloesungen braucht, wieso also keine OOP einsetzen? Anstatt vielen if-then-else oder switch, baut man einfach generische Objekte. OOP ist doch blos Datenkapselung, Vererbung und dynamische Objekte.
Man muss ja nicht C++ oder Python dafuer nehmen
-
DEvent schrieb:
sothis_ schrieb:
ich meine es sollte durchaus alternativen zu C und assembler im embedded bereich geben, das kann nicht schaden. aber objektorientierung hat im lowlevel sektor, gar nichts, aber auch rein gar nichts verloren, zumindest nicht auf heutigen prozessorarchitekturen
Wieso nicht? Wenn man OO-Problemloesungen braucht, wieso also keine OOP einsetzen? Anstatt vielen if-then-else oder switch, baut man einfach generische Objekte. OOP ist doch blos Datenkapselung, Vererbung und dynamische Objekte.
Man muss ja nicht C++ oder Python dafuer nehmen
warum? nagut, wenn ich einige hundert kilobyte SRAM habe mag das dann eine überlegung wert sein. aber wenn ich das lese was fricky da verlinkt hat schauderts mich. JavaVM auf AVR 8bit risc controllern. WARUM, WARUM nur machen die das? ich habe nur 2K SRAM und 32K flash für's programm nachdem ich diesen mist drauf habe habe ich nur noch 1K SRAM und 24K flash für's program. wofür? um das ding mit java zu programmieren? um ein paar pins abhängig vom programmablauf auf low oder high zu setzen, ein paar messungen mit dem adc durchführen und die timer konfigurieren, damit ich die PWM einsetzen kann, Ist dafür Java notwendig? um gottes willen nein. das macht nur jemand, der entweder absoluter oop fanboi ist, nicht c programmieren kann oder einfach nur beweisen will, dass es mit java geht und mit c++ nicht
-
µCs werden meistens in grossen stückzahlen verkauft und solange die kleinen chips billiger sind als grosse, und wenn es nur wenige cent sind, werden sie nicht aussterben.
Ist dafür Java notwendig? um gottes willen nein. das macht nur jemand, der entweder absoluter oop fanboi ist, nicht c programmieren kann oder einfach nur beweisen will, dass es mit java geht und mit c++ nicht
Beide Argumente (Kosten für Speicher, Low Level vs. High Level Programmierung) gab es bei der Entwicklung der PCs ebenfalls. Warum wird sich dennoch MS Vista als Betriebssystem und C#/.NET als Programmiersprache für die Windows-Programmierung durchsetzen? Fallende Preise für Prozessoren/Speicher und Bequemlichkeit/leichte Wartung. Bei den µC wird es sich in gewissen Bereichen ähnlich entwickeln. Für Elektronikmassenanwendungen ist ein kleiner Chip programmiert in ASM dann die bezüglich der Massenfertigung kostenoptimierte Variante.
Java gibt es sowohl für den Asuro (da macht es wirklich wenig Sinn), als auch für den Nibo (hier ist man in einem Grenzbereich). Im Robotikbereich werden sich "OS" und "Engines" durchsetzen, weil es keinen Sinn macht, immer die Basics neu zu programmieren.
-
Erhard Henkes schrieb:
Beide Argumente (Kosten für Speicher, Low Level vs. High Level Programmierung) gab es bei der Entwicklung der PCs ebenfalls.
ja, aber nicht so extrem. PCs sowie sämtlicher end-user schrott, lassen sich gut vertickern, indem man viel bunte reklame macht, sinnlose features einbaut und den leuten erzählt, sie würden sowas unbedingt brauchen. man kann die kisten teuer machen, weil der kundenkreis nach emotionalen kriterien kauft. schickes gehäuse, verchromter kühlkörper, marken-grafikkarte, etc. zählen mehr als ein gutes preis- leistungsverhältnis. im gegensatz dazu, kalkulieren µC-einkäufer knallhart. angenommen man hat die wahl zwischen einem 32bit-boliden und einem 8bit popelteil. für den 32-bitter würde die softwareentwicklung (in java) 2 wochen dauern, für den 8-bitter 6 monate (in assembler). weiterhin angenommen (der faktor 'time-to-market' wird hier mal vernachlässigt), man braucht 100.000 stück und der 32-bitter kostet 5 euronen mehr als der 8-bitter. dann kannst dir, glaub ich, gut vorstellen, für welchen µC man sich entscheidet.
-
Talla schrieb:
Der Borland Code ist C++ (wahrscheinlich noch aus einer Vor Standard Zeit) mit irgend ner Bibliotheksfunktion die da mitkommt, aber halt C++. Der zweite Code mit dem Convert::String ist wirklich eine andere Sprache: C++/CLI. Sie ist zwar "abwärtskompatibel" zu C++, aber nur zur Interoperabilität, sie ist und bleibt eine .Net Sprache mit ihren Vor- und Nachteilen. Convert:ToString ist aber wiederum nichts C++/CLI spezifisches sondern eine Bibliotheksfunktion von .Net.
Danke! Genau das ist die Antwort die ich ersucht habe
Es geht doch!
-
sothis_ schrieb:
warum? nagut, wenn ich einige hundert kilobyte SRAM habe mag das dann eine überlegung wert sein. aber wenn ich das lese was fricky da verlinkt hat schauderts mich. JavaVM auf AVR 8bit risc controllern. WARUM, WARUM nur machen die das? ich habe nur 2K SRAM und 32K flash für's programm nachdem ich diesen mist drauf habe habe ich nur noch 1K SRAM und 24K flash für's program. wofür? um das ding mit java zu programmieren? um ein paar pins abhängig vom programmablauf auf low oder high zu setzen, ein paar messungen mit dem adc durchführen und die timer konfigurieren, damit ich die PWM einsetzen kann, Ist dafür Java notwendig? um gottes willen nein. das macht nur jemand, der entweder absoluter oop fanboi ist, nicht c programmieren kann oder einfach nur beweisen will, dass es mit java geht und mit c++ nicht
Was hat OOP mit Java zu tun?
Zu der NanoVM: Ist halt blos eine Abstraktionsebene, damit man nicht auf einen Compiler/Hardware beschraenkt ist. Wenn man also moeglichst viel Hardware abdecken will, dann ist die NanoVM sicher gut.
-
DEvent schrieb:
Zu der NanoVM: Ist halt blos eine Abstraktionsebene, damit man nicht auf einen Compiler/Hardware beschraenkt ist. Wenn man also moeglichst viel Hardware abdecken will, dann ist die NanoVM sicher gut.
das kann man auch mit C, ohne dass viel veränderungen am code notwendig wären, zumal µC-programme sowieso schon extrem in ihrer größe begrenzt sind (zumindest auf den 8-Bit varianten). übersichtlichkeit kann da auch nicht die motivation gewesen sein. nunja offensichtlich wirds ja auch seit 2006 nicht mehr weiterentwickelt