EV3 BCC / C software problem(s)

[holler]

edit: Most compiler errors as I now see concern the API which is still different from the NXT API.
I'll try to fix them and I'm curious if it will then compile without issues.

Just change TextOut to TextOutEx and OnFwd to OnFwdReg or OnFwdSync

BTW: How to stop and restart tasks by other tasks intermediately?

Stopping other threads without their knowledge is broken by design. You don't stop other threads, you ask them to stop. Guess what happens if you kill a thread which currently is in a conversation with a motor. The motor might not be amused that his conversation partner suddenly disappeared.

Alexander Holler

[HaWe]

if I want to stop a motor control task I currently simply expect it to stop and abort immediately (e.g. if any motor stalling and around-spraying blood has been detected anyhow).
Additionally (and if wishful and needed), of course the stop_thread calling task may stop then also each single concerned motor individually.

But of course (e.g., for subsumption programs) multiple reasons are conceivable why one (superior) task may wish to stop or restart a (lower priority) task (out of which reason ever).

if the task (or a maybe completely different one) has to be restarted later under certain circumstances (e.g. if an obstacle has been removed or circumnavigated) , it should be possible then to proceed by restarting this task again.

[holler]

if I want to stop a motor control task I currently simply expect it to stop and abort immediately (e.g. if any motor stalling and around-spraying blood has been detected anyhow).

That expectation is wrong.
If we take your task from your previous post:

Code: Select all

void MotorControl() {
  int speed;

  while(true) {
    speed=Random(201) - 100; // ergibt eine Zufallszahl für die Motorleistung  zwischen -100 und +100
    OnFwdReg(OUT_A,speed);
(1)
    speed=Random(201) - 100;
(2)
    OnFwdReg(OUT_B,speed);

    speed=Random(201) - 100;
    OnFwdReg(OUT_C,speed); (3)

    Wait( 200+ (Random(2800)) ); // ergibt eine Zufallszahl für die Aktionsdauer von 200 - 3000 ms
  }
}

If you now kill this thread, you might kill it at (1) or (2), but you might even kill it inside (3), that means inside that OnFwdReg() which is in sending a command to the motor. Nothing but the thread itself does know where the thread currently is. So it is impossible to kill a thread from the outside while beeing sure nothing bad happens.

So you have to change how you do handle threads because it was wrong.

Alexander Holler

[HaWe]

how to handle what's happening and what has to be done additionally if a thread has been stopped from outside is another problem, but it must be possible in principle at any time to stop any thread by any other different thread from outside immediately .
Surely in single cases one has to think about how to sweep up the mess after aborting.

The same it's about restarting threads from outside at any time by any thread.

With NQC, NXC and RobotC it always was possible - and must be possible in future for subsumption programs.

[gloomyandy]

Doc, NXC, NQC, RobotC all run as an interpreter (with byte code). The VM that runs this code does a lot of work that is hidden from you, one of the things it does is to take care of things like this. When you get rid of the byte code you also get rid of some of the things it did for you. This problem is not unique to C, basically a solution requires that the run time system has pretty much complete knowledge about everything that the program and surrounding environment has been doing and how to get all of that back into a safe state. This is just about possible in a closed interpreter based system like those used for NXC etc. but not for more general purpose languages. The people that designed Java got this wrong and as a result had to make changes later. See the following link for some details of the problems that this caused:
http://docs.oracle.com/javase/6/docs/te ... ation.html

[HaWe]

Andy,
I know all that.
In most cases semaphores are working well to signalize tasks if they should run or not - but not always.
In certain cases (e.g., emergency stop/break) a task has to be aborted immediately, not sooner or later.
Then it's of no importance if there is something messed up by that thread_stop.
If my 25 kg robot threatens tumbling down the stairs then every behavior has to be stopped at once, period, or about the value of a second hand car is crushed.
Or if my lawn mower robot is driving dangerously close right towards our guinea pig while maneuvering, well, I don't like to imagine.

The decision I have to make is simply: Is, under these restrictions, BCC/C the correct platform for my projects?
For my programs I have a couple of requirements to the programming platform, and if BCC/C fits to them I would gladly use it.
I'm just about to try figuring out what the features are like and where the restrictions are located.

My requirements for my current project are:
1) C-based language supporting recursions
2) support of ev3 hardware plus all NXT-compatible hardware including sensor a/o motor multiplexers
3) convenient and easy controllable preemptive multitasking including start/stop tasks at any time by any other task
4) daisy chaining ev3s a/o NXTs to plug over all at least 20 sensors and 15 motors
5) data messaging/interchange with message control between the bricks

If it won't be possible by C, then I will have to try to wait and find another programming environment.
Since 6 years I am stalling on this project because 4) and 5) are not available for my NXTs, and it will make no sense to get 4) and 5) and have to abandon 2) and 3).

And ok, if I will run into trouble with C (and my skills for that) and on the other hand VMs are generally more suitable for my purposes then I will have to take a VM.

[gloomyandy]

Doc if your emergency stop method leaves the motor driver in a state that has the motors running full speed and unable to accept new commands then your guinea pig may well be wishing your thread_stop had not messed things up.

Oh and I would not want to be trusting the life of my pet to people who thought they were building a toy for a child, with tight deadlines, rather than a mission critical real time system. If you plan to control anything that could do real damage then I would urge you to review the code that is used to control it very carefully. The reason why things like Java and the pthreads libraries do not support things like thread_stop is because a lot of skilled people have looked at the issues of trying to make these sorts of things operate safely and constantly every time and they have decided that it is just not sensible to do so. It is better to not get into this situation in the first place.

Good luck with your search, and good luck to your guinea pig!

[holler]

Andy,
I know all that.
In most cases semaphores are working well to signalize tasks if they should run or not - but not always.
In certain cases (e.g., emergency stop/break) a task has to be aborted immediately, not sooner or later.
Then it's of no importance if there is something messed up by that thread_stop.
If my 25 kg robot threatens tumbling down the stairs then every behavior has to be stopped at once, period, or about the value of a second hand car is crushed.
Or if my lawn mower robot is driving dangerously close right towards our guinea pig while maneuvering, well, I don't like to imagine.

Why do you confuse stopping a motor with stopping a thread / task?

Code: Select all

bool stop = false;

void motor_thread(void)
{
        while(stop == false) {
                motor_go_forward_or_whatever();
                sleep(duration);
        }
}

void emergency_stop(void)
{
        stop = true;
        all_motors_stop();
}

Problem solved.

Update to explain the code above:
You just have to make sure, that your motor task doesn't turn the motor on again, after the emergency_stop has turned it off.

2. Update:
I currently only can support the suggestion of gloomyandy to not trying to use the EV3 for those tasks you mentioned.

Alexander Holler

[HaWe]

The emergency stop task was only one example when tasks e.g. control moving forward or backward or curves and regardless what thread currently is active it has to be quickly aborted. Of course, normally we also put our pets from the lawn into cages before starting mowing the lawn. But who knows? - _ship_happens_...

Additionally after stop_task then motor stops have to be induced additionally, that's what I meant by " sweep up the mess after aborting".
But one has to get everything under full control so that no thread becomes unwillingly restarted again. And another tricky thing is that

Code: Select all

sleep(duration);

Anyway, I need that thread_kill and thread_start, also of other reasons and for different circumstances.
Mainly for big robots, and so admittedly some things may sometimes become a little more dangerous to man and animal and machine.

But apart from that it's also useful to have easy task control if one is just tinkering with robot toys.

Back to the source:
what is this @@ thing for?

Code: Select all

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

[holler]

The emergency stop task was only one example when tasks e.g. control moving forward or backward or curves and regardless what thread currently is active it has to be quickly aborted. Of course, normally we also put our pets from the lawn into cages before starting mowing the lawn. But who knows? - _ship_happens_...

Additionally after stop_task then motor stops have to be induced additionally, that's what I meant by " sweep up the mess after aborting".
But one has to get everything under full control so that no thread becomes unwillingly restarted again. And another tricky thing is that

Code: Select all

system("poweroff -f");

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.

Regards,

Alexander Holler