How to calibrate light sensor using nxc?

[afanofosc]

The EV3 VM is nothing at all like the NXT VM and as such it is not byte code compatible. I am having to write a whole new assembler layer and code generator below the C-like VM-targetting compiler I am working on. I am also working on native code generation options from C/C++ and Pascal.

I hope to have preliminary/rudimentary/rough/buggy support for the EV3 in BricxCC by the end of July.

John Hansen

[HaWe]

why would we need both a quick C compiler for machine code and a comparativley slow bytecode interpreter if both have the same functionality and both are intergrated into the same IDE ?
Or will be differences in the functionality though?
in case: which?

[mightor]

The VM takes care of a lot of the timing aspects that come with dealing with the lower level calls. An abstraction library can do things like interface with the underlying hardware but that won't solve the timing and polling issues, you'd still have to deal with that yourself. So a language that compiles to the rather fast EV3 VM will do all that work for you.

= Xander

[HaWe]

AFAIK there already is an implementation for multitasking coming with C11 (gcc 4.6 and higher), most likely taking into account already related timing aspects.
Hardware polling is a matter of specific hardware polling functions and user interfaces of #included header files.

Of course I know that you as a RobotC programmer and a RobotC co-worker prefer a bytecode interpreter like RobotC has (or will still have).

A well-designed and widely-used VM (e.g., dalvik, jvm, .net) can have substantial benefits such as the ones aswin mentions. It is also true, though, that VMs can make things much more difficult than targetting a very well known processor and operating system, such as arm/linux, with widely used and standard programming languages, such as C/C++ and Pascal and with well known debugging tools like gdb. One of a kind VMs tend to make life difficult for both tool providers and tool consumers.

Just for example, the Fischertechnik RoboTX controller (also having an embedded ARM9) is programmed by a graphical interface (comparable to NXT-G), supports MT, recursions, motor control, analog sensor polling and i2c bus commands, BT and USB extensions, but the compiler generates genuine ARM9 machine code.

Anyway, finally it's a question what the specific API functions of each version and implementation are able to do.

Not generally but specifically.

So my question to John actually was if his implementations of the C API for genuine machine code and the EV3-C API for a bytecode interpreter will be the roughly same - or, in case, in which aspects they will not.
I guess just John will know what will be and what - probably - not.

[afanofosc]

Providing a VM-targetting compiler makes sense since most EV3 owners will be running the standard EV3 firmware and that firmware provides a PC communication layer plus a VM for user-written executables plus VM-based brick daisy chaining. Talking to an EV3 running the standard firmware from a PC-based IDE will be a lot easier than talking to an EV3 without the VM running (currently). It will be trickier to get the native code communication layer working to the same level of ease on 3 transport layers (usb, bluetooth, and wifi) since that does not exist right now. And user-written native arm-linux executables can't ask the VM to send daisy-chain commands to other bricks connected via USB without somebody writing the code to make that communication happen correctly. With the standard EV3 firmware that's available now for user-written VM executables.

So my plans are to support both but there will be a lot of work required to get all the native stuff working as seamlessly as the VM-based stuff. I'm not certain at this point which one will get "done" quicker. By "done" I mean "moderately usable and needing plenty of enhancements".

John Hansen

[HaWe]

thank you for you explanations, John.

Based on my experience so far, of course I've been secretly afraid of the difficulties of network problems (not only) for the native code compiler .

Having to control up to 20-30 sensors and 12-15 motors, this was already a well-known issue for the NXT (E)FW what made me finally sacrifice all my projects - fervently hoping that the new technology will eliminate the old difficulties. So a stable, user-friendly, and trouble-free network protocol (maybe needing a specific additional hardware like TCP/IP does, or maybe establishing an extra EV3 acting as a network server) will be indispensable for a renewed commitment in my opinion.

[mightor]

So my plans are to support both but there will be a lot of work required to get all the native stuff working as seamlessly as the VM-based stuff. I'm not certain at this point which one will get "done" quicker. By "done" I mean "moderately usable and needing plenty of enhancements".

It won't be trivial by any means. Not having to rewrite a lot of the code to make it play nice without the VM will probably be quicker, though

Don't expect the daisy chaining working in a native C programming environment any time soon. Motors and sensors will be highest priority, anything after that is gravy

= Xander

[HaWe]

nxtOSEK already managed to handle all of these problems on a real-time- operating system (featuring *.oil files for task priorities and real-time execution), also generating native machine code (CMIIW) - unfortunately providing only very poor user support.

[mightor]

It requires more than a simple header file to make a multi-tasking framework. nxtOSEK was based on years of design and collaboration between very bright minds of several car manufacturers. A compiler that does not preclude the use of threads is one thing, all the code that does the actual work is quite another. Maybe we can make it work with the QP framework from these guys: http://www.state-machine.com/qp/index.php.

We'll have to see

= Xander

[HaWe]

yes, OSEK was a project of a consortium of the biggest European car manufacturers and automotive suppliers like Bosch, Siemens, VW, Mercedes Benz, Peugeot, ... - but they all already had there own private technologies before, OSEK was just a project to establish a European open source industry standard for automotive realtime and multitasking processing.
Anyway, not only nxtOSEk was able to generate native machine code executables, also fischertechnik managed to do this for their RoboTX-ARM9.
But we're actually not talking about OSEK or fischertechnik. They were meant to be only examples that a native C code compiler is basically able to handle this complex realtime-and-multitasking-and-communication stuff.

I'm no technician or computer scientist, I'm simply a pharmacist and a medic - that's why I must say that I don't understand anything of this firmware- and compiler- programming thing.
I see it and need it just from the standpoint of an interested hobbyist who uses and needs some programming functionalities (like a car customer who uses and needs some car functionalities to drive a family car or a SUV or a sport car without having to construct the mechanics and to program the electronics by himself before starting to drive).

And for my personal purposes, daisy chaining and sensor and motor remote control is quite as important as local control - I have absolutely no use for 1 single EV3 if not at least 4x daisy chainable (the more, the better, preferably >= 400kBit/s wireless and full duplex).