Really Unexpected Task Behavior

[spiked33]

I'm a newb, so I'm probably doing something wrong - but I put together a small test program to see if it behaved the way a bigger program did. Actually it got worse

safecall void trace(string T) {
byte s = SendResponseString(MAILBOX1, T);
}

task TaskA() {
trace("TaskA");
while (true) {
trace("TaskA loop");
Yield();
}
}

task TaskB() {
trace("TaskB");
while (true) {
trace("TaskB loop");
Yield();
}
}

task main() {
trace("main");
priority TaskA,2;
priority TaskB,2;
Precedes(TaskA, TaskB);
}

produced;
##trying connection
##got connection
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
....forever

Would someone shed some light on this please.

[afanofosc]

You should try this without your priority statements and without using the mailbox system. The priority statement specifies the maximum number of statements to execute before yielding to another task. 2 statements (asm - not NXC) is way too small. But I'd totally remove that and recommend that it not be used in general.

I'm not sure where you are getting the produced output from. Can you elaborate on that? It takes many milliseconds to execute a direct command to read a mailbox value over bluetooth. Every 5 ms you will overflow your mailbox. Are you reading these from the NXT via another NXT or a PC connected via Bluetooth or are you using some other connection to access these mailbox messages?

John Hansen

[spiked33]

NXT to PC via bluetooth. It got better (the mailbox time explains lost messages), but still not what I was hoping for;

It still could be lost messages I suppose, but it would be pretty hard to tell if they rolling across an NXT screen. oh well, the code I'm playing with ATM (non directly controlled line follower, the light sensor is on its own motor, and drive follows it) doesn't really need tasks anyhow - I think I'd be better off with a loop in main.

What do you advanced guys use for debugging? Please don't tell me the LCD screen.

safecall void trace(string T) {
byte s = SendResponseString(MAILBOX1, T);
}

task TaskA() {
trace("TaskA");
while (true) {
trace("TaskA loop");
Wait(50);
Yield();
}
}

task TaskB() {
trace("TaskB");
while (true) {
trace("TaskB loop");
Wait(50);
Yield();
}
}

task main() {
trace("main");
Precedes(TaskA, TaskB);
}


##trying connection
##got connection
TaskB
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskA loop
TaskB loop
TaskB loop
TaskA loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskA loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskA loop
TaskB loop
TaskB loop
TaskA loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop
TaskA loop
TaskB loop
TaskB loop
TaskA loop
TaskB loop
TaskA loop
TaskB loop
TaskB loop
TaskB loop
TaskB loop

[mcsummation]

Wait(50) causes the task to stop running, so the Yield() doesn't really do anything.

[afanofosc]

Having no idea what you are trying to do it is hard for me to make any useful suggestions.

Yield, by the way, is equivalent to Wait(MS_1) so there is no reason to call Yield if you are calling Wait just prior to it.

Also, SendResponseString is already thread-safe. You should avoid adding another layer of mutexes if you don't need them. Make your trace function inline or just a simple #define rather than a safecall function.

John Hansen

[spiked33]

This is my first 'fully self' project, from LDD for the first time, to NXC for the first time to really programming on the NXT for the first time, so expect a thousands mistakes. Add to that a 38+ year programmer, who has always used 'printf' as a debugging tool when nothing else is available, and I'm kind of set in my ways. I'm a total newb with tons of experience, the worst combination

I am making a line follower, but being me, I did not want to do it the way I've seen it done 1000 times before. I once saw a non-NXT bot using a WebCam that followed the line, and the robot steered to the WebCam. It ran circles around everyone else as far as speed. So, I tried to do something similar, where the light sensor is on its own motor, and it tries to follow the line, ahead of the bot, and the bot steers to it. Having started my career doing re-entrant multiprocessing code, I thought this thing should be quick enough to handle that. And wanting trace statements, not scrolling on a tiny LCD I can't see, I wrote a quick ReadMailBox app on the PC to show them.

So I probably made a dozen wrong assumptions, but in the end, I got it to work, albeit a lot slower than I had hoped. The processor is simply not fast enough for the sensor to stay ahead of the vehicle motion, even after eliminating all mailbox/wait/task stuff. Well maybe it is, I should say I was not able to get it to go fast enough to keep up without slowing down the bot quite a bit, there might be ways that I will figure out down the road.

http://youtu.be/oOohs1Wf6Nk

Anyhow thanks a ton for what you said so far. It saved me from going down a path guaranteed to fail. I'm sure I will have more questions later

Still curious on debugging techniques. Are there alternatives to the LCD? Even the onboard dataLogging, dumped later might be helpful.

[pepijndevos]

I'm quite sure it is possible to log data to the NXT filesystem, I'm not sure about the API though.

Have you considered making a PID line follower?

[spiked33]

I'm quite sure it is possible to log data to the NXT filesystem, I'm not sure about the API though.

Have you considered making a PID line follower?

that was the "I did not want to do it the way I've seen it done 1000 times before" part. I'm sure PID would improve what I've got now. But if I get the ratios in the program better, it is kind of a mechanical PID, sorta.

[pepijndevos]

Fair enough.

It seems syscall is what you need for file access http://bricxcc.sourceforge.net/nbc/doc/ ... df655be551

[mcsummation]

It seems syscall is what you need for file access http://bricxcc.sourceforge.net/nbc/doc/ ... df655be551

SourceForge seems to be down right now.

If you look at fprintf in the NXC guide, it's probably what you want. Several of the "regular C" functions are implemented in NXC. I'm using fgets to read a script for Odin.