ev3dev: C für EV3

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

Moderator: Moderatoren

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 8. Mai 2015 00:43

HaWe hat geschrieben:
Ich verstehe nicht, wieso native Executables unter der Lego-FW langsamer laufen sollten als mit Java oder Mono

tun sie auch nicht -
das ist eine Eigenheit der Lego-FW:

Linux läuft, klar, aber auch die Lego-VM läuft immer als task, weil man ohne sie nicht auf die Module für Buttons, Bildschirm, USB etc zugreifen könnte (Linux-Fachleute können das sicher besser erklären).
Wie Xander Soldaat es mal erklärte:
wenn man die Lego VM abschaltet, würde man den Ast absägen, auf dem man sitzt.

Daher kann man zwar schnelle Ecexutables erzeugen (gpp C mit code sourcery Lite toolchains, wie das wohl heißt), aber parallel zu den executables läuft nach wie vor die Lego-VM als Parallel-Task - und das kostet natürlich cpu-Power.

Dämlich, aber wahr. :-pc:

Fiel mir gar nicht auf, als ich für die mal programmiert habe. Habe aber auch nicht drauf geachtet. Könnte man aber beenden, wenn man sie nicht braucht. Wundert mich eh, dass sie derart viel Ressourcen verbraucht, wenn kein Programm außer dem Menu läuft.

Das hat aber nichts mit Linux zu tun. Worauf die VM läuft ist für das Programm unwichtig. Man braucht rein technisch gesehen auch keine VM, um auf die Module zugreifen zu können, auch nicht, wenn es einfach gehen soll.


Java hat eine eigene FW und einen JIT-compiler (Mono ebenso), die machen nach und nach ihre "eigenen" "executables".

:mrgreen:

Wusste gar nicht, dass Java auch JIT Compilation macht. Dachte, die führt stupide ihren Bytecode aus. Aber ergibt zumindest Sinn, sonst wäre es wohl noch langsamer. :D

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

Re: ev3dev: C für EV3

Beitragvon HaWe » 8. Mai 2015 07:43

für wen ("die") hast du was mal programmiert und womit?

die Lego VM greift wohl tiefer ins System ein, als man so denkt. Das war auch der Grund, weshalb Xander, Robomatter (RobotC) und National Instruments (=NI: Labview) eine neue Enhanced VM (EVM) entwickelt haben, so dass man flexibler auf die Module zugreifen kann und der Kontakt zum Brick nicht auf verschiedenen Ebenen abbricht, wenn man sie abschaltet. Mit der alten ging es jedenfalls definitiv nicht (laut Xander).
Die RC/NI-EVM für DaVinci ist darüber hinaus Open Source, und sie ist abwärtskompatibel zur Lego-VM, man könnte sie also auch anderweitig nutzen.
Andererseits ist aber das ihr immer noch zu Grunde liegende DaVinci Linux extrem mangelhaft ausgestattet, ansonsten hätte sich Ralph Hempel ja auch nicht ans Debian drangesetzt.

Dass Java und Mono JIT-Compiler auf EV3 benutzen, erkennst du an den Benchmarks:
Die erste Iteration ist extrem langsam, erst später (ab der 4./5. Iteration) holen sie auf.
Trotzdem erreichen beide im Benchmark unterm Strich (bestenfalls, auch nach der 5.It.) nur etwa 1/3 der Gesamtperformance der BCC/gpp/C-Executables
(bestenfalls ~750ms vs. C≈250ms, score bestenfalls 70.000 vs. C≈190.000).
ev3dev-Debian sehe ich hier sogar schon in der Nähe von 250.000, wenn Daisy Chaining und multiple Netzwerk-Funktionen implementiert sind (guck dir da mal die Features von leJOS an!).
Übrigens schafft Debian mit seinen toolchains auch double (wie auf Raspbian) und bis zu 9-dimensionale Arrayoperationen sowie C11 inkl. MT oder wenigstens C2009 mit pthread: das gibt ne Menge Environment-Bonuspunkte! :mrgreen:
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 8. Mai 2015 11:00

HaWe hat geschrieben:für wen ("die") hast du was mal programmiert und womit?

Die Original Firmware. Als Grundlage diente diese Seite: http://www.robotnav.com/ev3/
Ich habe die CodeSourcery Toolchain genutzt. Bzw. habe ich hier noch andere ARM Toolchains rumliegen, die gingen auch. Die Interaktion mit den Motoren und Sensoren war aber grässlich, weil die Dokumenation zu Großteilen im Quellcode ist und man sich da irgendwelche Dateinamen raussuchen muss, die man dann direkt auf Speicherbereiche mapt. Hier ein Beispiel für die Motorenkontrolle: http://www.robotnav.com/open-loop-control/

die Lego VM greift wohl tiefer ins System ein, als man so denkt. Das war auch der Grund, weshalb Xander, Robomatter (RobotC) und National Instruments (=NI: Labview) eine neue Enhanced VM (EVM) entwickelt haben, so dass man flexibler auf die Module zugreifen kann und der Kontakt zum Brick nicht auf verschiedenen Ebenen abbricht, wenn man sie abschaltet. Mit der alten ging es jedenfalls definitiv nicht (laut Xander). Andererseits ist auch das DaVinci Linux extrem mangelhaft ausgestattet, sonst hätte Ralph Hempel sich ja auch nicht ans Debian drangesetzt. Allerdings ist die RC/NI-EVM für DaVinci Open Source, und sie ist abwärtskompatibel zur Lego-VM, man könnte sie also auch anderweitig nutzen (oder evtl. auch leichter abschalten).

Sagen wir mal so. Ich habe gerade die Original Firmware mal gestartet und geschaut, was im Hintergrund läuft. Jap, lms2012 hat so ~50% CPU Last. Also ich es killen wollte, ging dann gar nichts mehr. Wahrscheinlich war die Telnetshell ein Kind-Prozess und damit auch gekillt. Müsste man sich mal genauer anschauen. Ich habe auch zuerst probiert direkt mit der Lego Firmware zu arbeiten, habe sogar schon einige Motorfunktionen in schöne C-Funktionen gekapselt. Aber mit dem Debian Treiber ging das alles nochmal einen Zacken besser, weil das Treiberinterface viel durchdachter ist. Außerdem hab ich mehr Ahnung von Debian und wenn mal was fehlt, kann ich es selbst schnell nachinstallieren. Auch, dass die Originalfirmware nur mit einem WLAN-Stick geht, ist nervig (auch wenn ich den habe). Irgendwann will ich halt mal Bildverarbeitung machen und wenn ich mir den Webcamtreiber nichst selbst kompilieren muss, ist das schon fein.

Dass Java und Mono JIT-Compiler auf EV3 benutzen, erkennst du an den Benchmarks:
Die erste Iteration ist extrem langsam, erst später (ab der 4./5. Iteration) holen sie auf.
Trotzdem erreichen beide im Benchmark unterm Strich (bestenfalls, auch nach der 5.It.) nur etwa 1/3 der Gesamtperformance der BCC/gpp/C-Executables
(bestenfalls ~750ms vs. C≈250ms, score bestenfalls 70.000 vs. C≈190.000).
ev3dev-Debian sehe ich hier sogar schon in der Nähe von 250.000, wenn Daisy Chaining und multiple Netzwerk-Funktionen implementiert sind (guck dir da mal die Features von leJOS an!).
Übrigens schafft Debian mit seinen toolchains auch double (wie auf Raspbian) und bis zu 9-dimensionale Arrayoperationen sowie C11 inkl. MT oder wenigstens C2009 mit pthread: das gibt ne Menge Environment-Bonuspunkte! :mrgreen:

Ah, deshalb stand da immer loopX!
Klar, der GCC ist schon ein sehr herausragender Compiler. Ich habe deinen Benchmark mal um die Ausgabetests gekürzt und unter Debian kompiliert und laufen lassen:

So ist das Ergebnis mit -O3:

Code: Alles auswählen

  0       2  int_Add
  0       1  int_Mult
  0      49  float_op
  0       2  randomize
  0       1  matrx_algb
  0      42  arr_sort


Und so ohne Optimierung:

Code: Alles auswählen

  0       2  int_Add
  0      15  int_Mult
  0      48  float_op
  0       4  randomize
  0       6  matrx_algb
  0     100  arr_sort


Die Gesamtzahlen und die Reziproke spar ich mir mal, fehlt ja noch was. Wenn ich meine Ausgabebibliothek um Textausgabe auf dem EV3 Bildschirm erweitert habe (Das wird gerade alles im Terminal ausgegeben), kann ich den Test auch mal komplett ausführen, wenn Interesse besteht. Wer die optimale Ausnutzung der Hardware will, ist mit ev3dev scheinbar gut beraten. ;)

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

Re: ev3dev: C für EV3

Beitragvon HaWe » 8. Mai 2015 11:03

oh ja, unbedingt, den test hätte ich wirklich sehr gerne mal komplett für ev3 dev! 8-)

welcher Compiler ist das?
was macht -O3: ?
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 8. Mai 2015 11:21

Das ist der "GCC Compiler". Das der Standardcompiler unter Linux. http://de.wikipedia.org/wiki/GNU_Compiler_Collection

-O aktiviert Optimierungen (das klappt übrigens bei den meisten Nicht-Microsoft Compilern). Dahinter kommt eine Zahl, die die Stärke der Optimierung angibt. -O3 ist im Moment die höchst mögliche, hat es aber in sich. Kann Benchmark Ergebnisse aber auch stark verfälschen. So etwas

Code: Alles auswählen

int y = 0;
int i;
for (i = 0; i < 10; i++)
  y += i;

kann der schonmal zu

Code: Alles auswählen

int y = 45;
int i = 10;

optimieren. ;)

Deshalb habe ich beide Werte angegeben. Gerade bei der Matrixmanipulation scheint der mit -O3 ein paar Abkürzungen zu nehmen. ;)

Edit: Man möge sich bitte mal die Diskrepanz zwischen meinem Rang und meiner Beitragszahl anschauen. :D

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

Re: ev3dev: C für EV3

Beitragvon HaWe » 8. Mai 2015 11:29

das wäre ntl unzulässig, ich habe aber die unzulässigen Optimierungen versucht durch volatile auszuschalten - dann dürfte das bei -O3 doch nicht passieren, oder?
Ansonsten sind Optimierung schon ok, was macht -O2 ?


andere Frage:
BricxCC nutzt ja auch gpp (GCC) und CSLite - und hat das makefile dafür...
kann man das nicht einfach für ev3dev umschreiben, sodass man BricxCC dann auch auf ev3dev nutzen kann?

Code: Alles auswählen

PROGRAM=%PROGRAM%
DOBJECTS=%DOBJECTS%
TOOLPREFIX=%TOOLPREFIX%

all:: realclean $(DOBJECTS) $(PROGRAM)

download:: all

#pscp -scp -pw "%PW%" %PROGRAM% root@%IPADDR%:%FOLDER%

clean::
   rm -f *.o *.ppu *.rst

realclean:: clean
   rm -f $(PROGRAM)

FLAGS=%FLAGS%
LDFLAGS=-Wl,-R/media/card/lib, -lpthread, -lmath

CC=$(TOOLPREFIX)%CCNAME%

# how to link executable
%PROGRAM%: %MAINSRC%
   $(CC) $(FLAGS) $(LDFLAGS) $< -o$@ %LINKOBJS%

# how to compile source
%.o: %%EXT%
   $(CC) $(FLAGS) %LINKONLY% $< -o$@
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

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

Re: ev3dev: C für EV3

Beitragvon HaWe » 8. Mai 2015 11:38

zum Rang:

Ziz
Weniger als 15 Beiträge
Beiträge: 15

wahrscheinlich ist das die Zählung wie bei C: beginnt bei 0,
dann stehst du also bei 14,
und das ist weniger als 15 :mrgreen:

also stimmt es doch , haha! :lol:
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 8. Mai 2015 11:48

Haha, lustig, das macht das, was ich mir auch überlegt hatte: Das Kopieren mittels SCP.

Prinzipiell ginge das schon, aber ev3dev greift ja ganz anders auf die Hardware zu als die Originalfirmware. Man müsste also die Bibliothek, die BrixCC da nutzt erstmal für ev3dev portieren. Oder man müsst innerhalb von BrixCC halt die eigenen Funktionen nutzen. Müsste mir das Programmchen mal genauer ansehen, um zu schauen, ob es als Arbeitsgrundlage taugt. Wäre natürlich schön.

Hier stehen die Optimierungen, die der GCC bei O1, O2 und O3 aktiviert:
https://gcc.gnu.org/onlinedocs/gcc/Opti ... tions.html

Volatile bringt wirklich eine Menge. Ohne sieht das ganze so aus mit -O3:

Code: Alles auswählen

  0       0  int_Add
  0       0  int_Mult
  0      49  float_op
  0       1  randomize
  0       1  matrx_algb
  0      41  arr_sort

Die Datei ist auch kleiner, also hat er wirklich einigen Code einfach nicht mitkompiliert. Ich denke mit den volatiles kann man schon -O3 machen. :)

Zum Rang: Leute bis 19 Beiträge haben auch einen Rang von "weniger als 15 Beiträge". :P

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

Re: ev3dev: C für EV3

Beitragvon HaWe » 8. Mai 2015 12:34

vielleicht rechnet er nicht "Beiträge", sondern "wirklich echt sinnvolle Beiträge" :mrgreen:

die Matix macht mich stutzig - vllt doch besser -O2 ?
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 8. Mai 2015 12:57

Mit dem Volatile sollte -O3 eigentlich aussagekräftig bleiben, wenn ich mir die aktivierten Optimierungen so ansehe. Das Problem ist imho halt eher, dass der Benchmarkcode im Ganzen schon sehr stark die Optimierung der Schleifen testet, insbesondere für die Matrixmultiplikation. Es ist also schon aussagekräftig, man muss nur Bedenken, dass die Matrixmultiplikation weniger die Gleitkommaverarbeitung als mehr die Schleifenverarbeitung testet. ;)

Nichtsdestotrotz der Wert ist sehr klein, aber skaliert linear. Wenn ich 25.000 statt 250 Schleifendurchläufe mache, bekomme ich einen Wer von 117 ms. Mit 2.500 einen Wert von 12 ms. Also optimiert er die Schleife scheinbar nicht weg. ;)

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

Re: ev3dev: C für EV3

Beitragvon HaWe » 8. Mai 2015 13:38

super umgesetzt! :)
habe sodann bereits die Benchmark-Tabelle erweitert um ev3dev 8-)

ist deiner der gleiche Code wie hier?
http://www.mindstormsforum.de/viewtopic.php?f=71&t=8095&p=64494#p64494

oder abgeändert?
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 8. Mai 2015 14:01

Ja, der gleiche Code, aber ich mache die Zeitmessung anders und habe halt alles rausgeschmissen, was Firmwarespezifisch ist (LCD Zeug und so). Ich werde das aber basierend auf meiner Implementation aber wieder einbauen, um die letzten Messwerte zu bekommen. ;) Ich kann den Code am Ende hier posten, wenn du magst.

Was ich aber noch gar nicht richtig verarbeitet habe: Was spricht eigentlich gegen BrixCC, abgesehen davon, dass es nicht ev3dev nutzt?
Edit: Ah, scheinbar ist EV3 seit ein paar Jahren auf der ToDo? :\

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

Re: ev3dev: C für EV3

Beitragvon HaWe » 8. Mai 2015 14:18

es gibt absolut keine Sensor-API bei BCC/C, außerdem sind die Sensoren (sogar auch bei robotnav) extrem schwer zugänglich.
(robotnav wiederum verwendet nicht BCC als IDE, sondern eine eigene auf der Basis von Java und Eclipse :( )

Was man bräuchte, wäre eine explizite Sensor-Deklaration für BCC/C ähnlich wie bei NQC oder NXC, nur erweitert auf Werte-Arrays:

Code: Alles auswählen

SetSensor(char port, int type, int mode);
int * SensorValue(char port, int * intvalue);


außerdem sehe ich noch nicht, ob und wie BCC/C Daisy-Chaining unterstützt... :(

und klar: auf jeden Fall interessiert mich dein Code! :)
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
Ziz
Schreibt ab und zu
Schreibt ab und zu
Beiträge: 36
Registriert: 16. Apr 2015 17:45
Kontaktdaten:

Re: ev3dev: C für EV3

Beitragvon Ziz » 8. Mai 2015 14:54

HaWe hat geschrieben:es gibt absolut keine Sensor-API bei BCC/C, außerdem sind die Sensoren (sogar auch bei robotnav) extrem schwer zugänglich.
(robotnav wiederum verwendet nicht BCC als IDE, sondern eine eigene auf der Basis von Java und Eclipse :( )

Was man bräuchte, wäre eine explizite Sensor-Deklaration für BCC/C ähnlich wie bei NQC oder NXC:

Code: Alles auswählen

SetSensor(port, type, mode);
int16_t * SensorValue(port, * intvalue);


außerdem sehe ich noch nicht, ob und wie BCC/C Daisy-Chaining unterstützt... :(

und klar: auf jeden Fall interessiert mich dein Code! :)


Meinst du RobotC statt RobotNav? Ansonsten weiß ich nicht, was du meinst. Also bei ev3dev sind alle Sensoren Dateien in /sys/class. Wie das eine Bibliothek dann umsetzt, ist ihr wohl selbst überlassen, die meisten Objekt orientieren nutzen wohl direkt Objekte. Ich mache das so in meiner Bibliothek:

ev3_load_sensors erstellt eine Liste mit allen momentan angeschlossenen Sensoren

Code: Alles auswählen

ev3_sensor_ptr sensors = ev3_load_sensors();


Man kann durch die Liste von Hand durchiterieren oder bewusst nach einem Namen oder einem Port suchen. ev3_search_sensor_by_identifier sucht nach einem Namen wie LEGO_EV3_TOUCH (alle Definitionen sind hier https://github.com/theZiz/ev3c/blob/master/ev3c.h#L68 ), ev3_search_sensor_by_port sucht nach einem Sensor an einem bestimmten Port, Beispiel:

Code: Alles auswählen

ev3_sensor_ptr touch_sensor = ev3_search_sensor_by_identifier(sensors,LEGO_EV3_TOUCH,1);

Der letzte Parameter, die "1", sagt, dass nur noch nicht geöffnete Sensoren in die Suche mit einbezogen werden wollen. Recht praktisch, wenn man mehr als einen Sensor des gleichen Typs angeschlossen hat. ;)

Mit ev3_open_sensor muss man den Sensor danach erstmal öffnen, um damit arbeiten zu können. Der Grund ist, dass die Datei mit den Sensorwerten die ganze Zeit geöffnet bleiben sollte, um schneller an die Daten zu kommen. Dateien öffnen und schließen ist relativ zeitaufwendig. Das will man nicht jedesmal machen, wenn man Sensordaten liest. ;)

Code: Alles auswählen

ev3_open_sensor(touch_sensor);


Nun kann man den touch_sensor verwerden. Die zuletzt gelesenen Sensorwerte liegen in den Arrays touch_sensor->bin_data oder touch_sensor->val_data. Es sind Arrays, da einige Sensoren mehr als einen Wert liefern, der Farbsensor z.B. die Farbkomponenten. Sie werden aber nicht automatisch aktualisiert, das macht man mit ev3_update_sensor_bin(touch_sensor); bzw. ev3_update_sensor_val(touch_sensor);. Die zweite Funktion rechnet einem die Messwerte dabei in semantisch sinnvolles Werte um. Bei dem Touchsensor wäre das 0 für nicht gedrückt und 1 für gedrückt. Die bin_data sind für Touchsensoren z.B. 0 oder irgendwas größer als 100, aber wechselhaft. Wahrscheinlich sind das intern die Spannungen mit irgendeinem Faktor. Aber schneller auszulesen. Ich lasse dem Nutzer die Wahl, was er will. Sehr schnell und roh oder langsamer (aber immer noch schnell) und vorverarbeitet. ;)

Mit ev3_close_sensor schließt man die Sensoren wieder und mit ev3_delete_sensors löscht man die Eingangs erstellte Liste von allen angeschlossenen Sensoren, wenn sie geöffnet waren, schließt es sie auch gleich. Das klingt vielleicht kompliziert, ist aber total einfach. Kleines Beispiel.

Sei ein Roboter, der genau einen EV3 Touch Sensor oder NXT Touch Sensor angeschlossen hat. Das Programm soll laufen bis der Sensor gedrückt wird. Das sähe so aus:

Code: Alles auswählen

ev3_sensor_ptr sensors = ev3_load_sensors();
ev3_sensor_ptr touch_sensor = ev3_search_sensor_by_identifier( sensors, LEGO_EV3_TOUCH, 0 );
if (!touch_sensor)
  touch_sensor = ev3_search_sensor_by_identifier( sensors, LEGO_NXT_TOUCH, 0 );
if (!touch_sensor)
{
  printf("Kein Touch Sensor gefunden, Exit\n");
  return 1;
}
ev3_open_sensor( touch_sensor );
while ( touch_sensor->val_data[0].s32 == 0 )
  ev3_update_sensor_val( touch_sensor );
ev3_delete_sensors(sensors);


Einziger kleiner Stolperstein ist noch das .s32 bei val_data[0]. Der Grund: val_data ist ein Array von unions, da einige Sensoren int Werte zurückliefern, einige aber auch floats. Was man benutzen muss, steht in der Dokumenation oder man schaut in touch_sensor->bin_data_format. ;)

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

Re: ev3dev: C für EV3

Beitragvon HaWe » 8. Mai 2015 15:12

hi,
das ist mir jetzt schon ein wenig zu detailliert, ich glaube, da muss man erst noch mal reinfinden mit der Zeit, am besten anhand von Beispielen.
ich selber bevorzuge eine komplette manuelle Initialisierung , und keine automatisch per ev3_load_sensors() angezeigte Liste der angeschlossenen Sensoren, (denn ich will kein autodetect, was bei 3rd-Party Sensoren und per i2c-gemultiplexten Sensoren eh nicht funktioniert). Aber mal abwarten.

zu robotnav (http://www.robotnav.com/, https://github.com/robotnav/Ev3 ):
das war ein user, der eine eigene (Java+Eclipse-basierte) IDE und API für TI DaVinci-Linux-Executables entwickelt hat, als Ersatz für BCC/GCC, weils damit nicht weiterging. Sie griff direkt auf die lms2012.h Modul-Schnittstelle zu, was sie extrem unverständlich und unübersichtlich machte.
Hätte er BCC als IDE verwendet statt seine eigene, wäre die Hürde schon ein wenig niedriger gewesen, aber Java und Eclipse mit ihren Monster-Installationen kommen mir nicht auf meinen Computer... :twisted:
(so ging es wschl nicht nur mir, denn eine Resonanz unter EV3-Nutzern war nicht wahrnehmbar, was wieder mein Credo bestätigt:
-> einfache Installation + einfache IDE + einfache API ... : sonst wird das nichts mit der Community! )
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 15 Gäste

Lego Mindstorms EV3, NXT und RCX Forum : Haftungsauschluss