But my question was about coding start task and stop task.
Back to the source:
what is this @@ thing for?
Code: Select all
@@ -5,6 +5,7 @@
...
@@ -16,7 +17,7 @@
Code: Select all
@@ -5,6 +5,7 @@
...
@@ -16,7 +17,7 @@
Doc is the #1 de-motivator for me when it comes to trying to create tools for the LMS community. I apologize if that annoys him, but it is true. Nothing I do meets with his approval and he spreads a ton of FUD that surely negatively impacts other potential users of my tools.Anyway, it doesn't make sense from my point of view to further take part in this discussion. I've tried my best and obviously failed.
That's part of the output of diff and is not part of code. Delete those lines. Good luck using C++11 with the EV3 firmware and CSLite 2009q1-203 (aka gcc 4.3.3).
Good luck using C++11 with the EV3 firmware and CSLite 2009...
Yes, that doesn't work. You need at least gcc 4.7, but I already mentioned that. What is possible is to use a newer CSLite and -static in CFLAGS. The resulting binaries will become around 1MB, but they will be able to run with(out) the very old glibc the EV3 uses. Sorry, I haven't had a look a the new Bricxcc up to now, so I don't know if and how that might be possible to intregrate.afanofosc wrote:Good luck using C++11 with the EV3 firmware and CSLite 2009q1-203 (aka gcc 4.3.3).
I may be wrong but did I hear rumors that you were working on a C++ API for the EV3? If so, I would strongly prefer a collaborative effort than a competitive effort. If you are working on an API and choose not to collaborate it will be another reason why I may decide not to complete my work toward an API for the EV3.holler wrote: Btw., thanks for Bricxcc, even if I seldom used it because I'm a long time Linux user. But I remember I did had at least a look at it several years ago.
(I made a break in playing with the NXT)
so then finally it was the right decision, everything is good and everyone is happy.My addition of start and stop to NXC was only driven by their presence in NQC and had nothing whatsoever to do with Doc.
I don't want to compete and would prefer a collaborative effort too.afanofosc wrote:I may be wrong but did I hear rumors that you were working on a C++ API for the EV3? If so, I would strongly prefer a collaborative effort than a competitive effort. If you are working on an API and choose not to collaborate it will be another reason why I may decide not to complete my work toward an API for the EV3.
I don't follow you here. What part of a native arm-linux C/C++ API do you think would not be usable with the current EV3 drivers/firmware? The code I have written so far works flawlessly with the current EV3 drivers and firmware. Sensor usage is less than perfect but it is still very usable - especially for all the EV3 sensors. I2C devices may be a bit problematic but it is likely a native API will at some point require an enhanced EV3 firmware image which enables some additional capabilities without breaking the VM behavior if it is running. I should have a usable API for sensors done in the next few days, if I can find some free time.holler wrote: I don't want to compete and would prefer a collaborative effort too.
But unfortunately I currently don't see how it might become usable with the current EV3 drivers/firmware. So even minimal support would be a nightmare and I fear to publish even the beginnings. Maybe an upcoming SDK of LEGO will shed some light on the correct usage of sensors. I don't know if such is planned by LEGO.
But I don't want to continue talking about that topic in the public. We shouldn't forget that the EV3 was designed to be used by kids through the supplied software and that seems to work without problems.
Users browsing this forum: No registered users and 1 guest