Neuer EV3, wie weiter? - Gedankenspiele

NXC, C/C++, Lejos, pbLua, RobotC...

Moderator: Moderatoren

gjb
Weniger als 15 Beiträge
Weniger als 15 Beiträge
Beiträge: 18
Registriert: 10. Sep 2013 18:04

Neuer EV3, wie weiter? - Gedankenspiele

Beitragvon gjb » 19. Jan 2016 09:23

Betr.: viewtopic.php?f=25&t=8797

Hallo Murenius,

häufig ist der Weg ja der, dass man mit der grafischen Lego-Software anfängt, irgendwann an Grenzen stößt und sich dann mit alternativen Entwicklungsumgebungen befasst. Man möchte mehr Möglichkeiten, aber keine neue Hardware kaufen.

Mit Raspberry und Arduno ist man, was die Entwicklungsumgebungen betrifft, deutlich flexibler. Aber: Mann muss sich mit Sensorik und Aktoren selbst befassen. Da gibt es nichts, was man einfach zusammensteckt und dann funktioniert es. OK, bei http://learn.makeblock.cc/wiring/ geht es in die Richtung.

Da ich auch den Hauptvorteil von Lego, robust, fast unkaputtbar und ich muss mich um die Hardware nicht kümmern. Den Hauptnachteil sehe ich in der Begrenzung der Sensor- und Aktoranschlüsse. Besonders die nur vier Eingänge finde ich bedauerlich.

Was ist denn Deine Motivation, mit einem neuen EV3 Richtung Hochsprache zu gehen?
Beste Grüße Gerhard
expermentiere mit NXT | EV3 | mBlock | Arduino

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5384
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: Neuer EV3, wie weiter? - Gedankenspiele

Beitragvon HaWe » 19. Jan 2016 10:20

also da muss ich widersprechen - ich selber habe nie die grafische Programmierung benutzt, weder beim NXT noch beim EV3. Wer mit C und Java programmieren kann, der wird damit auch kaum warm werden.
Immerhin wäre aber EV3Basic noch eine Schriftvariante für Einsteiger, mit der Lego-Firmware.
Außerdem geht es nicht um "normalerweise" oder "typisch", sondern um ein spezifisches Problem.
Der TO hat ja ganz gezielt nach ev3dev und C++ etc. als Schrift-Programmierung (oder gleichwertigen oder sogar besseren Alternativen) gefragt, also sollten wir hier schon beim Thema "Schriftprogrammierung" bleiben und jetzt nicht anfangen "die Frage in Frage zu stellen".

Wenn also jemand noch Ideen zu C++/ev3dev-Tutorials hat, immer her damit, ansonsten lassen wir ihn erstmal antworten, er war ja auch seit seinem Post ab dem 17.1. nicht mehr hier eingeloggt.

ps,
Anmerkung:
Tatsächlich hat der EV3 nicht 4, sondern 8 Eingänge - man vergisst meist, auch die 4 Quadraturencoder-Eingänge mitzuzählen, die in den Motorports integriert sind. Daher hat der EV3 4 Motorausgänge, 4 Quadraturencoder-Eingänge und 4 weitere frei konfigurierbare Sensoreingänge (ADC, I2C, UART), zusammen also 12 IOs - plus 1 USB host.
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

gjb
Weniger als 15 Beiträge
Weniger als 15 Beiträge
Beiträge: 18
Registriert: 10. Sep 2013 18:04

Neuer EV3, wie weiter? - Gedankenspiele

Beitragvon gjb » 27. Jan 2016 18:08

HaWe hat geschrieben:also da muss ich widersprechen - ich selber habe nie die grafische Programmierung benutzt, weder beim NXT noch beim EV3. Wer mit C und Java programmieren kann, der wird damit auch kaum warm werden.


Das mag ja sein, aber der typische EV3-Benutzer hat mit dem EV3 zum
ersten Mail etwas Programmierbares in der Hand und kennt weder C
noch Java.

HaWe hat geschrieben:sollten wir hier schon beim Thema "Schriftprogrammierung" bleiben und jetzt nicht anfangen "die Frage in Frage zu stellen".


Ich habe nichts in Frage gestellt, sondern nach der Motivation
gefragt. Ist ja soweit geklärt.

HaWe hat geschrieben:Tatsächlich hat der EV3 nicht 4, sondern 8 Eingänge - man vergisst meist, auch die 4 Quadraturencoder-Eingänge mitzuzählen, die in den Motorports integriert sind. Daher hat der EV3 4 Motorausgänge, 4 Quadraturencoder-Eingänge und 4 weitere frei konfigurierbare Sensoreingänge (ADC, I2C, UART), zusammen also 12 IOs - plus 1 USB host.[/i]


Ok, verstehe, mittels Mechanik und Motor könnte ich
mir selbst einen Taster bauen.

Aber anscheidend macht das niemand. Zumindest erweckt
diese unbeantwortet Frage den Eindruck, dass mit den
Encoder-Daten niemand arbeit (außer der Stein selbst):

viewtopic.php?f=74&t=8788
Beste Grüße Gerhard
expermentiere mit NXT | EV3 | mBlock | Arduino

gjb
Weniger als 15 Beiträge
Weniger als 15 Beiträge
Beiträge: 18
Registriert: 10. Sep 2013 18:04

Re: Neuer EV3, wie weiter? - Gedankenspiele

Beitragvon gjb » 27. Jan 2016 18:14

Murenius hat geschrieben:
Um ganz ehrlich zu sein hatte ich auch eher erwartet, dass ihr erfahrenen Entwickler direkt diverse Links zu Alternativen hervorsprudelt, ich bin überrascht, dass das beim EV3 nach 2+ Jahren immer noch recht unbearbeitet ist. Gefühlt gab es beim NXT mehr Zeug, den hatte ich damals recht einfach mit NXC benutzt, fragt mich aber nicht mehr wie genau, das ist bald 10 Jahre her.


Ich vermute mal, dass heute, im Vergleich zu NXT-Zeiten, häufig
auch Arduinos und Raspberrys einsetzt werden, um Roboter zu
bauen und das Programmieren zu lernen. Und da ist die Auswahl
an Programmiersprachen nahezu unbegrenzt.

Der Nachteil ist, dass man sich um die Hardware selbst kümmern
muss, bei Lego stecke ich die zusammen und funktioniert – ganz
ohne Kurzschlüsse und verbogene Pins.
Beste Grüße Gerhard
expermentiere mit NXT | EV3 | mBlock | Arduino

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5384
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: Neuer EV3, wie weiter? - Gedankenspiele

Beitragvon HaWe » 27. Jan 2016 21:08

Murenius hat geschrieben:ich bin überrascht, dass das beim EV3 nach 2+ Jahren immer noch recht unbearbeitet ist. Gefühlt gab es beim NXT mehr Zeug, den hatte ich damals recht einfach mit NXC benutzt


Etwas populärwissenschaftlich verpackt... - Der grundsätzliche Unterschied zwischen NXT/NXC und EV3/C++ ist:

NXC ist ein Bytecode-Compiler, der Bytecode für die Lego VM erzeugt, der dann von ihr auf dem NXT interpretiert wird. Die VM hat alle spezifischen Funktionen bereits einprogrammiert und macht die ganze Arbeit bezüglich Sensor-, Motor-, Screen-, Button-, Sound-Zugriffe.
NXC macht dabei das gleiche wie die NXT-G-Bildchensprache, die den gleichen Bytecode generiert, und das auf einer relativ hohen Abstraktionsebene - die VM macht dann erst die ganze Arbeit. "Selber" muss NXC über die Hardware gar nichts wissen.
(Streng genommen wird NXC code erst in NBC code übersetzt, und dieser dann erst in Bytecode).

Der EV3 läuft nun zwar auf Linux, aber Linux ist nur das Betriebssystem, auf dem wieder "nur" ein Bytecodeinterpreter arbeitet, der den von EV3-G erzeugten Bytecode interpretiert.
Er hat eine Schnittstelle zu EV3-Hardware-Modulen, genannt "lms2012", dies bildet die sog. "Firmware".
Analog zu NXC erzeugt genau diesen Bytecode aber "heute auch schon" EV3Basic, indem es ebenfalls den gleichen, spezifischen Bytecode für die (EV3-) VM generiert, und auch hier wird die eigenliche "Arbeit" bezüglich Hardware-Zugriffe vom Bytecodeinterpreter geleistet.

C++ ist aber eine andere Liga, denn C++ erzeugt Linux Executables, die also dierkt auf Linux laufen. C auf Linux weiß aber nichts von Lego-Sensoren und Motoren, es kennt nur device trees und allgemeine Datei-Schreibfunktionen - denn alles unter Linux ist eine Datei. Nur wie bringt man Linux bei, welche Datei mit welchem Pfad zu erstellen und wie zu beschreiben oder zu lesen ist, wenn man damit einen Lego-Sensor steuern will ? Alles was vorher im Bytecodeinterpreter bereits einprogrammiert war, muss man jetzt wieder neu entwickeln, und es müssen wieder lms2012-Funktionen und Hardware-Module (die teilweise im Linux-Kernel compiliert oder dynamisch verlinkt waren) erneut eingelinkt werden.

Vorteil von C/C++ compilierten Executables: sie laufen 100x so schnell wie Lego Bytecode.

Erschwerend kommt nun aber hinzu, dass das Lego-Linux (TI DaVinci) auf seinem sehr kleinen Flash ein sehr zusammengestutztes Linux ist, das längst nicht alle sonst üblichen Linux-Funktionen besitzt, dass der Linux-Kernel nicht thread-safe ist, dass lms2012 wohl völlig verkorkst programmiert ist (beides Aussagen von Xander Soldaat, Programmierer der EV3-RobotC-Firmware) und Lego-Sensoren alles andere als Standard-Sensoren sind (vor allem I2C, aber u.a. auch UART), was die Nutzbarkeit zusammen mit C-Compilern nicht gerade vereinfacht.

Bytecode für den Interpreter und Linux-Executables sind aber auch 2 völlig verschiedene Welten, die grundsätzlich nichts miteinander zu tun haben, und daher muss man für ein "richtiges" Linux mit erweiterten Entwickler-Möglichkeiten alles komplett von Grund auf neu aufsetzen - das hat ev3dev gemacht:
ev3dev ist Debian Linux, mit neuen Modulen angepasst auf den EV3 und seine Sensoren und Funktionen (so wie Raspbian angepasstes Debian Linux für den Raspi ist), und es bringt die Debian-typischen Entwicklertools mit, um damit Programme schreiben zu können.
Nachteil:
Es kommt mit Entwicklertools und Libs, die hauptsächlch auf Python setzen (genau wie auf dem Raspi), und auch die Raspi-Entwickler konzentrieren sich auf Python (übrigens auch wieder ein Interpreter) und nicht auf C-Compiler.
Python wiederum ist aber auch genau so weit von C entfernt wie EV3Basic, das es ja nun auch bereits gibt.

Aber: bei ev3dev ist an etwas entscheidendem herumgedreht worden (sog. "device tree overlays", das betrifft die Pfade zu Dateien, die Geräte, Schnittstellen, Bussysteme und Ports repräsentieren), sodass einige übliche C-Entwicklertools damit wieder nicht mehr laufen. Das merkt man dort, wo man ev3dev und Debian alternativ einsetzen kann, nämlich auf dem Raspi: Bestimmte wichtige und gute Raspbian-Libs sind inkompatibel mit ev3dev-Debian.

Toll, gelle?

Da schließt sich der Kreis: C auf Debian-Linux ist wenig supportet, weder für EV3 auf ev3dev noch auf dem Raspi (BickPi, PiStorms), das bisschen, was man an guten Linux-C-Libs nutzen könnte, läuft nicht mehr mit ev3dev (z.B. wiringPi), und damit ist man dann also noch immer kaum einen Schritt weiter, was C-Compiler für den EV3 angeht - außer dass man jetzt etwas vollständigere Möglichkeiten hat, es möglicherweise "grundsätzlich" besser tun zu können.

wie geagt, alles etwas populärwissenschaftlich verpackt. Allzu starke Vereinfachungen bitte ich mir nachzusehen...
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E


Zurück zu „textbasierte Programmiersoftware“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 34 Gäste

Lego Mindstorms EV3, NXT und RCX Forum : Haftungsauschluss