EV3 BCC / C software problem(s)

[HaWe]

no, it doesn't make sense to discuss with me about the reason or workarounds.

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 @@

[afanofosc]

For one thing, I do not think that if you stop a task (which I added as a feature of the enhanced NXT firmware) that it will stop the motors. For one thing nothing in the firmware knows (iirc) that task A was the task that "owned" the motors. If all tasks are stopped, i.e., the program terminated, then the VM likely shuts down the motors also. I suspect if you run a test with NXC on the NXT that you will be inclined to not control your lawn mower with an NXT running the enhanced NBC/NXC firmware - or your 25kg robot about to fall down the stairs.

I would not even assert with any degree of confidence that the RCX 2.0 firmware and NQC behaved in that fashion either, i.e., stopping motors started by a task when that task is stopped. Ditto for playing tones or any other resource that could be "started" with an unspecified duration (i.e., run until told to stop).

If you want to yank the rug out from under another task then the task that does the rug yanking is responsible for cleaning up the mess it may cause.

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.

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.

John Hansen

[afanofosc]

what is this @@ thing for?

Code: Select all

    @@ -5,6 +5,7 @@
    ...
    @@ -16,7 +17,7 @@

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).

John Hansen

[HaWe]

IIRC you added this start / stop task to NXC after I added this to the wishlist (or if some things went wrong with the 1st implementation), because it was an important feature - and before it was also successfully featured by NQC (CMIIW).
And after that it was a real improvement, so I consider my suggestions as constructive.

Of course I don't expect to stop motors by stopping a task, I already said that one might have to stop single motors additionally. But the task has to be aborted first, maybe immediately.

You should not always mistake to consider suggestions for improvements as if they were meant to disqualify the work you're doing. Not everyone who is not completely your opinion or makes suggestions to change a thing is actually attacking you or your work personally.

edit - thanks, just saw it has overlapped with your post.

this little sarcasm of course I have just discovered now so I guess you think all this won't work ever at all

Good luck using C++11 with the EV3 firmware and CSLite 2009...

[holler]

Good luck using C++11 with the EV3 firmware and CSLite 2009q1-203 (aka gcc 4.3.3).

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.

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)

Alexander Holler

[afanofosc]

I am not an expert on the interactions between statically linked arm-linux binaries and an embedded arm linux OS built with an older compiler with dynamic linking to older libC versions. If that works, great. To create statically linked binaries just add -static to the LDFLAGS variable in the BricxCC makefile template. And you are welcome to try the latest CodeSourcery Lite cross compiler if you want to use C++11. I do not plan on spending any time on that. I may add a checkbox that says "use static linking" and have that cause BricxCC to add that option behind the scenes but it is easy to add via the template.

My addition of start and stop to NXC was only driven by their presence in NQC and had nothing whatsoever to do with Doc.

John Hansen

[afanofosc]

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)

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.

John Hansen

[HaWe]

My addition of start and stop to NXC was only driven by their presence in NQC and had nothing whatsoever to do with Doc.

so then finally it was the right decision, everything is good and everyone is happy.

[holler]

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 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.

Alexander Holler

[afanofosc]

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.

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.

In any case, if you would prefer to collaborate but you would prefer not to talk about it in public then would you be willing to email me at bricxcc @ comcast . net?

John Hansen