Page 1 of 1

BricxCC EV3 download program

Posted: 29 Mar 2014, 02:53
by cpapple123
Where does the program go? Sure I ran the Test program and all ran as expected but the program does not appear on the EV3 screen to run again. Also when I explore the EV3 from BCC the Test.c is there. When I cycle the power the program is gone.

Re: BricxCC EV3 download program

Posted: 29 Mar 2014, 08:03
by HaWe
the ev3 screen does not show any Linux executables at all, just artefacts which are misinterpreted by the Lego GUI intermediately.

Re: BricxCC EV3 download program

Posted: 30 Mar 2014, 00:00
by cpapple123
Didn't BricxCC create executable for the NXT? I'm not up to speed with the EV3 differences. I just received mine last week from my wife for our anniversary. I am not a huge fan of the new Lego software feels real stripped down even from the NXT-G software. I liked/ was used to the function blocks in NXT-G with the options window that accustomed each block and really like the flexibility of BricxCC. As I now poke around the web it feels that LEGO has not as freely opened the book for the EV3 as they did for the NXT. Maybe in time? I hope so I always love the Idea that lego Open the book on the NXT because "hackers" expanded the possibilities way beyond their imaginations.

Re: BricxCC EV3 download program

Posted: 30 Mar 2014, 07:00
by HaWe
heya,
no, BCC/NXC created bytecode just like NXT-G for the Lego NXT VM bytecode interpreter
EV3-G creates bytecode, too, but for the EV3 VM of course (which is completely different from the NXT bytecode interpreter)
but BCC/EV3-C creates Linux executables by a real C compiler (gpp CSLite) , that has nothing to do with the Lego VM (except that there are often bad interactions if the Lego VM is running simultaneously as it always does with the standard Lego firmware).

IMO these issues should have been already made more clear in any BCC instruction/readme files.

Both ev3 hardware and software specifications are published and available, but the Lego firmware is quite bugged as some people reported and the C compiler is using large parts of it's library (or modified parts of it) - and it's still rudimentary and probably will not be completed and fixed "in a future of a kind which commonly is called 'near' " (if not possibly never).
Different approaches to kind of an API by other members often are incompatible either to John Hansen's API or to the original firmware libs (e.g., lms2012.h), or both, and they also are rudimentary, too.
No one really seems to care for the present time or for the future, though.