Helmut Wunder

Forum Replies Created

Viewing 15 posts - 31 through 45 (of 92 total)
  • Author
    Posts
  • in reply to: benchmark test: HaWe brickbench – for C# / Mono? #4621
    Author Image
    Helmut Wunder
    Participant

    Vlad,
    about Mono/C# , I meanwhile updated the Mono/C# benchmarks acc. to your results:
    http://www.mindstormsforum.de/viewtopic.php?f=71&t=8095&p=64772#p64772
    Any news about the “?” positions?

    about your RobotC tests: is it the same source which I have published?
    http://www.mindstormsforum.de/viewtopic.php?f=71&t=8095&start=60#p64501

    if not: could you please send me a link to the RobotC source code you have been using?
    There meanwhile is a 4.25 pre-release but there is no test result output any more, surprisingly, as reported by a different user:
    http://www.mindstormsforum.de/viewtopic.php?f=25&p=65395#p65382

    kind regards,
    Helmut

    in reply to: benchmark test: HaWe brickbench – for C# / Mono? #4595
    Author Image
    Helmut Wunder
    Participant

    short addendum:
    found your matrix and sort benchs, I missed them before! http://www.mindstormsforum.de/viewtopic.php?f=71&t=8095&start=75#p65290
    Added ’em already to the table! http://www.mindstormsforum.de/viewtopic.php?f=71&t=8095&p=64772#p64772

    in reply to: benchmark test: HaWe brickbench – for C# / Mono? #4594
    Author Image
    Helmut Wunder
    Participant

    Vlad,
    thank you very much for your input and for your cooperation – I was afraid you might perceive my post as sort of rude, I apologize if you might have had this impression – but it was only meant to avoid obsolete data to misrepresent the real comparison at any later date which would be unfair to the other tests (not sure if I could express my intention correctly). Of course you are free to publish your own results which is in your own responsibility – and I certainly would appreciate if you’d publish them singularily without showing different platform data!

    Indeed some changes meanwhile have been made in the RobotC VM which lead to a quicker runtime performance.
    The code and the test have been written and performed by Xander Soldaat, and he wrote me that especially the sort algorithm is meanwhile replaced in an internal build by an intrinsic test with the speed comparable to Linux executables.
    As soon as the new RC build has been released he surely will publish the updated results.
    If you like, you certainly may perform the RC test and publish them, too (with a date time and a RC version stamp), and I then will gladly always update the newest results in the comparison chart. As I don’t have RC, I can’t do the tests by myself.
    BTW, there are additional issues about the leJOS benchmarks and I’m waiting for Andy Shaw’s fixes, too, to include them as well, just post them please directly here in the forum again if you wish!

    About Mono/C#:
    Now I also understand the loop thing in your table. It appears to be something similar to the Java JIT (just-in-time) compiler. Actually it’s complicated to unite all those runtime data for each VM and each loop in my spreadsheet table – finally it would be bursting at the seams. Maybe just loops #1 + #3 would give a representative cross-section about this, I’ll add them ASAP.

    Just to outline what the rest of the benchs is about (of course I know that you won’t know all the details without exception):
    I would appreciate to get to know the matrix and the sort tests, possibly also the text_out. If there is no graphic lib, we’ll have to skip that thing (nxtOSEK also provides no graphic lib, but Martin Aumair wrote and published his own lib so that it could be performed).
    About memory: is there a memavail() function where you can read this SRAM mem during runtime? Is it up to 64MByte like gpp C or even more, maybe up to all built-in 264 MByte?
    Is the code size limited in either way?
    About BT or daisy-chaining or multi-robot-communication and all that: Do you have an idea if direct I/O control is possible? Is there something written in the documentation? (The Lego FW provides 1+3 for USB daisy chaining and 1+7 for raw BT comm).
    The multi-dim array thing is about how to manipulate multi-dim arrays, e.g. after beeing passed to functions. If you wish to compare the gpp C code to the RobotC or the nxtOSEK code you’ll recognize what I mean:
    by gpp C, you can access both rows and columns individually/seperately, in other cases this is not possible, one has to multiply the rows by number of columns to access the cell in a virtual linearized array.
    The first feature is the better one, of course, and this is what this point is about.
    The last things about int, long, and float already have been answered in our German forum (you are welcome to join it!): http://www.mindstormsforum.de/viewtopic.php?f=71&t=8095&p=65299#p65297

    The last line is about API completeness:
    – can motors be commanded to run certain degrees by certain pwm? Is there a PID control to approach encoder targets?
    – can all sensors of Lego EV3 and NXT kits be polled? Are there general i2c functions to poll 3rd party devices, too (even chained ones by reading/writing different single addr and data registers)?
    – Screen API is complete AFAIK for writing text to any (x,y) position, graphics are not available as already mentioned.

    Anyway, thanks again for your interest, your input and thanks for sharing your code! 🙂

    in reply to: benchmark test: HaWe brickbench – for C# / Mono? #4592
    Author Image
    Helmut Wunder
    Participant

    hello,
    thank you very much, I gladly take the Mono C# results up into my table.

    Please notice that according to Copyright restrictions it is not allowed to publish your own tables:

    © Helmut Wunder 2013,2014.
    HaWe brickbench test Comparison tables/speadsheets and results are copyright protected and may not be freely created, copied and / or distributed. Additions and / or changes in the tables require written permission by the author.
    HaWe brickbench test – Vergleichstabellen und Ergebnisse sind urheberrechtlich geschützt und dürfen nicht frei erstellt, kopiert und/oder verbreitet werden. Ergänzungen und/oder Veränderungen der Tabellen bedürfen der schriftlichen Genehmigung durch den Autor.
    http://www.mindstormsforum.de/viewtopic.php?f=71&t=8095&start=60#p64772

    I also obeserved that you did not include the Copyright rules for the code itself:

    // hw brickbench
    // benchmark test for NXT/EV3 and similar Micro Controllers
    // PL: . . . . . . . . .
    // Autor: (C) Helmut Wunder 2013,2014
    // Ported to . . . . . by . . . . . .
    // freie Verwendung für private Zwecke
    // für kommerzielle Zwecke nur nach Genehmigung durch den Autor.
    // protected under the friendly Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License
    // http://creativecommons.org/licenses/by-nc-sa/3.0/
    // version 1.08

    I gladly publish both your C# code and your C# results in my results table, and of course you may link to my results tables in my Thread, but please delete your table which you have refered to in your own link.

    Please understand that these precausions unfortunately had to be taken to prevent faulty and/or uncornfirmed data to be disseminated.

    Please send me a link with all published and needed files in raw text code format (just blanks, no tabs), compressed in a zip folder. Github is far too confusing, additionally I need to have the access to the files in my own thread.

    Last but not least a couple of questions:
    – why do you have different “runs” – what does it mean? How have to be interpreted the divergent data ?
    – what about the display bench mark? (As you might observe e.g., for RobotC and Java, grafic benchmark partially have a big influence on the overall benchmark)
    – also some data are needed for memory specs provided by C#:
    runt. code mem.,
    variable mem.
    BT raw master+slave
    RS485/i2c raw master+slv.
    BT, +MC I/O rem.protocol
    RS485, +MC I/O rem.prot.
    USB MC Daisy-Chain
    WiFi MC I/O rem.protocol
    feat. double=64bit float
    feat.>=4D array/matrix oper.
    Multitthreading
    API complete (sensor+motor+screen)?

    Thank you very much again for your input!

    in reply to: benchmark test: HaWe brickbench – for C# / Mono? #4525
    Author Image
    Helmut Wunder
    Participant

    ps,
    link to the source code libs seemed to work faulty – this one should work:
    http://www.mindstormsforum.de/viewtopic.php?f=71&t=8095&start=60#p64499

    in reply to: Convenient IDE for Mono C# for EV3 needed! #4522
    Author Image
    Helmut Wunder
    Participant

    please stop your OT posting, this is not the topic of my thread – or are you just trolling?

    Being an admin (and a moderator of the Mindstorms forum, all over since > 8 years) should say: I know what people need and what they are asking for, I know almost each one of the thousands of posts and questions and issues.

    I already pointed out:
    IMO already the comparatively immensely small number of Mono users and the extremely small number of forum posts which are separated in time very far, shows that access to C#/Mono for most people is too difficult and deters and discourages.

    If the target group for C#/Mono is supposed to be kept small just for computer scientists who are already fine with using Eclipse or VS, then it’s ok of course, but if it’s supposed to be targeted to the formerly really huge group of NXC users (which was the largest NXT-text-based programming group world-wide) then both C#/Mono and the related API and IDEs have to be simplified a lot.

    in reply to: Convenient IDE for Mono C# for EV3 needed! #4519
    Author Image
    Helmut Wunder
    Participant

    “Max”, I know that you are experienced in using VS already since a long time – but this is not valid for the majority of EV3 users and home programmers. As an admin of the biggest European Mindstorms forum ( “www.mindstormsforum.de” • posts > 42000 • topics: ~5200 • members > 3800 ) I daresay: I know what I’m speaking about.

    IMO already the comparatively immensely small number of Mono users and the extremely small number of forum posts which are separated in time very far, shows that access to C#/Mono for most people is too difficult and deters and discourages.

    If the target group for C#/Mono is supposed to be kept small just for computer scientists who are already fine with using Eclipse or VS, then it’s ok of course, but if it’s supposed to be targeted to the formerly really huge group of NXC users (which was the largest NXT-text-based programming group world-wide) then both C#/Mono and the related API and IDEs have to be simplified a lot.

    • This reply was modified 10 years, 3 months ago by Author ImageHelmut Wunder.
    in reply to: Convenient IDE for Mono C# for EV3 needed! #4517
    Author Image
    Helmut Wunder
    Participant

    that’s the point:
    AFAIK it doesn’t exist a thing like this but IMO in it’s absence the user community will be limited to computer scientists or computer science students, hobby home programmers and beginners have no access and remain excluded as they already desparate during the install process and to upload the most simple sample programs.

    As BCC is open source and already supports Java, pbForth, BrickOS, NXC, and gpp C/C++ it just would have to be customized and adapted to Mono. It’s even running on Windows XP, 7, Linux, and Mac (CMIIW).
    A downsized Mono IDE with a Sketch-look-alike IDE of course would be fine, too.

    in reply to: Convenient IDE for Mono C# for EV3 needed! #4515
    Author Image
    Helmut Wunder
    Participant

    Visual Studio is no convenient, downsized IDE – it’s a monster like Eclipse, I already pointed that out!

    in reply to: Convenient IDE for Mono C# for EV3 needed! #4512
    Author Image
    Helmut Wunder
    Participant

    Zoltan,
    Would you please open a new thread about your Xamarin issues?
    My topic is more generally about super-simplified IDEs. Xamarin is for Apple – I don’t have Apple and it’s actually not what I would call “super-simplified” compared to Sketch IDE ode BCC IDE.

    in reply to: Convenient IDE for Mono C# for EV3 needed! #4510
    Author Image
    Helmut Wunder
    Participant

    ps, completely forgot to mention:
    daisy-chaining like it’s provided by the Lego FW is completely missing at BCC/C, too – and that’s too bad, because daisy-chaining is almost the only feature which particularly distinguishes the EV3 opposed to the NXT (NXC, RobotC).

    in reply to: Convenient IDE for Mono C# for EV3 needed! #4509
    Author Image
    Helmut Wunder
    Participant

    I’m not sure if I understand you both correctly:
    of course you can programm the EV3 via BCC and gpp C/C++ feat. Code Sourcery Lite 2009 toolchains:

    http://bricxcc.sourceforge.net/test_releases/readme_1st.txt

    but the API functions are rudimentary (no sensor API), partially incomplete (e.g., motors, screen) or missing (multitasking), and in other respects partially bugged (buttons, screen).
    E.g., in the current lms2012.h release it’s not possible to chain several different i2c devices to 1 sensor port and read or write them individually.

    Anyhow, multitasking has been successfully implemented by me using POSIX pthread (linked to dynamically via makefile):
    http://www.mindstormsforum.de/viewtopic.php?f=25&t=7991&p=63128&hilit=pthread#p63287

    Unfortunately many additional bugs are due to Lego firmware and module lib issues (lms2012.h). Many people say the Lego has really screwed and messed up that thing.

    There have been approaches to fix some bugs and extend API functions though (batchwise just for specific cases and meanwhile mostly stalling).

    But in my limited understanding it could be definitely possible to use BCC also for different firmwares or cross compilers (e.g., ev3def, C#/Mono).

    Java would be NEVER an option for me: far too many different classes and inaccessibly encapsulated objects!
    One should have 1 Ueber-Class
    class ev3robot
    which features and provides all methods and objects and procedures which currently have to be excruciatingly be searched and implemented and extended by other inaccessibly encapsulated classes.

    Moreover, already the IDE (Eclipse) is a big crap, starting off from the installation procedure.

    No way!

    in reply to: Convenient IDE for Mono C# for EV3 needed! #4503
    Author Image
    Helmut Wunder
    Participant

    Radoslav,
    your intention seem to counteract my intentions from my TOP:
    My intentions are to size-down either IDE to make it small and clear and customized to just let one program Mindstorms robots by it.
    So I suspect your post is off-topic here in my thread:
    A convenient, simple, down-sized, exactly-made-to-measure IDE for Mono C# for EV3/NXT is needed, similar to BricxCC for NXT/RCX and the Arduino IDE for C/Sketch for Atmel CPUs!

    And I don’t need anything for Apple devices:
    Apple is nothing else but: “High Walls and Holy Gardens”.
    So I never would purchase anything by Apple and won’t ever need anything for it.

    BTW, I also won’t ever need anything for Linux PCs.

    So all I ever needed is a crosscompiler for Windows (XP32 and 7/64) plus a super-downsized IDE for it.

    • This reply was modified 10 years, 4 months ago by Author ImageHelmut Wunder.
    in reply to: Convenient IDE for Mono C# for EV3 needed! #4489
    Author Image
    Helmut Wunder
    Participant

    well,
    actually Sketch C is not low-level-programming in my opinion. It’s more like NXC or RobotC, i.g. ANSI C featuring pointers and recursions plus C++ objects (which are automatically included).
    I/O pins are not much different from NXT or EV3 ports:
    You may read them digitally or analog, so readDigital(p) is like SensorTouch(p) and readAnalog(p) is like SensorRaw(p) or SensorADC(p).
    Driving a motor forward by x% pwm , e.g, On(p, pwm) for the NXT or EV3 is exactly like writeAnalog(p,pwm) for an Arduino.
    So to my experience -for robot programming – there’s 1 like the other.
    Even reading i2c sensor data is as easy as switching on a bedside lamp:
    while(Wire.available()) { i2cInput[i] = Wire.read(); ++i; }
    I meanwhile managed to set up a i2c connection between a NXT and an Arduino, I managed to set up simultaneous PID controls by NXC for the NXT and by Sketch for an Arduino. It was a matter of a couple of days to write it top-down, I didn’t have to struggle with new, implements, extends, derivate methods, throw exceptions, private or public or make one to the kind of the other, and I don’t have to deal with trillions of classes or uses or headers or dynamic linked libs and included project files or makefiles and all the mess.
    If I need a function foo or sensor or motor or screen access I just write it down and don’t need a class for it to combine a extend by another class. Sketch also uses objects, but I don’t need to think even 1 microsecond of what class it’s about.

    And if I compile a source file to an executable, I get just 1 executable file (what I expect to get) and not half a disk space full of directories and subdirectories and additional files and even more files and more extra sub-subdirectories and some where inside and in between there is – sic! – also the desired executable file – if you look hard enough.

    In this respect, C# plus Mono and VC is not much different from Lejos and Java plus Eclipse. It both strike me dead.

    As simple as Sketch and NXC as programming languages are, the same kind of simplicity is in the IDE which is needed an used: BCC and the Sketch IDE both are exactly-made-to-measure IDEs, no ballast which is not needed for robots.
    And all and everything installed and set up by just 1 single setup file.

    Finally I want to program just 1 (ONE) Robot with all available sensors and motors and additional I/Os (and not a high culture of robots and not a troop of webservers or multiplayer browser games).

    in reply to: interface an Arduino Uno as an i2c slave to EV3? #4478
    Author Image
    Helmut Wunder
    Participant

    any ideas for a transcoding?

Viewing 15 posts - 31 through 45 (of 92 total)
Posted in

Make a donation