EV3 I/O library

[HaWe]

ps
@mrblb
but IIRC, you are a professional programmer and you once promised to write a network protocol for BCC and C/Linux executables for both data transmission of variables and for I/O remote control like Aloha net or TCP/IP from EV3 to several other EV3s (possibly peer-to peer).
Is there already any progress?

[tcwan]

My preference would be to produce a standard API library which I think could be called brickOS/EV3, i.e., after the original brickOS for the RCX. My approach so far to this API has been to model the functions after the NXC API so that in C/C++ and Pascal you could write code that looks a lot like NXC code and have it run natively as an arm-linux app. If you have been following my progress with respect to BricxCC support for the EV3 you may have seen some videos I posted on YouTube showing off some bits of the API that I have working already. Of course, a higher level object oriented API for C++ and Pascal would be nice to have as well and there would be no reason to base that off of NXC API function names.

I really like the direction that this is heading in. I suppose there would not be any real incentive to run NBC files on the EV3, unless there is a chance for binary compatibility with the NXT (compile once, run on both?). The EV3 should favor the performance advantage of compile to native code otherwise.

Also, it would be possible to provide bindings for other languages (e.g., python), once the C API bindings have been defined.

In case somebody here is not completely aware, BricxCC currently supports compiling, downloading, and running native arm-linux executables on the EV3. There are a lot of things with respect to this support that need work/improvement but I used BricxCC to compile and download the snapshot binary which is what enables BricxCC's Screen Capture tool for the EV3 and you can launch that and other arm-linux binaries via the Explorer tool as well as via the Run toolbar button/menu option.

John Hansen

Hmm. I wonder if it would be better to focus on the downloading and remote-device control aspects ala Next Tool?
There are various Cross-platform IDEs available already (Eclipse being the common one people love/hate). This way you won't have to spend so much time worrying about the editor and build / make support.

[HaWe]

eclipse is far from a dimension like loving or hating it.
It'a a monster where you're drowned in an avalanche of settings and paths and libraries and platforms and what else.
Even already correctly installing eclipse is a nightmare.
Eclipse was the first-rate reason why I for instance never got in to Java and/or nxtOSEK.
No, please never let us be dependend on eclipse in order to use ev3-C, BCC is exceptionally well suited!

[tcwan]

eclipse is far from a dimension like loving or hating it.
It'a a monster where you're drowned in an avalanche of settings and paths and libraries and platforms and what else.
Even already correctly installing eclipse is a nightmare.
Eclipse was the first-rate reason why I for instance never got in to Java and/or nxtOSEK.
No, please never let us be dependend on eclipse in order to use ev3-C, BCC is exceptionally well suited!

You are right. I don't particularly like Eclipse myself.
However, it does have all the plugins which I need (git and scons integration, for my case), and is cross platform.

Anjuta http://www.anjuta.org/ is a nice lightweight IDE but as far as I know it is not available for Windows? I haven't tried getting it to work on Mac OS X. Not sure what plugins are available (though the site says that it is extensible).

[afanofosc]

I deleted a couple posts that were not particularly helpful. My apologies if that annoys anyone.

John Hansen

[mrblp]

Hello,

as you addressed me personally:
I am no Linux programmer, I didn't work with any Linux PC ever, I have no idea of this operating system and it's commands, I am no hardware programmer, I never learned anything about information technologies or computer science, and I never used gcc or gpp or eclipse so far (and probably never will use this monster), I am just a simple API-end-user who uses a C-based programming language instead of Lego icons. From my point of view, programming an API would be more the business of people who have learned and/or studied programming and computer science.

OK, I understood. Perhaps someone else will do it. I won't.

but IIRC, you are a professional programmer and you once promised to write a network protocol

I won't do this as I never promised it. Perhaps you did not read my latest post to this topic carefully enough?

[HaWe]

yes, maybe, and maybe Google translate didn't translate it carefully enough.