Muti-threading
 

I want to know everyone's opinion on threading. Would you like to have the ability to create threads for the RC, or are you happy with the way the things are now?

(For those of you who don't know, having threads is a way of allowing mutiple things to be happening in your code at the same time and independently.)

Re: Muti-threading
 

I'm not certain, but I doubt this would substantially improve performance.

What I need is a math library, readily accessible... how can one live without exponentials, hyperbolic secants, and zeta functions!? :confused: :ahh:

I realize that many are available (like the open source Sun Microsystems library, which we ended up using) but it is difficult, with a large library, to pick out the functions you actually need. A library in the firmware or somehow better accessible, with only the functions that one really would need, like trig/powers, would be quite welcome.

Re: Muti-threading
 

I'm not necessarally thinking of performance, in fact, unless done well, this might slow it down some. (very little) I'm really thinking of the advantages of being able to have, say, a thread that is continuously running, watching encoders on the wheels and ensuring they are turning at the correct rates for the desired turn/staight. :)

Re: Muti-threading
 

I guess that it might be nice to have them just as another option. It is nice to have more than one way of doing things. I personally never use threads for anything. But then I don't do robot programming (but if I did robot programming, I wouldn't use threads anyway).

Re: Muti-threading
 

it wouldnt be too much of a problem to have and use threads but do oyu really have that much use for them ? Theres not really that many things you would need to have running at once? I think it would be agreat idea but I am at a loss as to what would it be used for. I also dont know what kinda crazy programming things you guys do some times.

Re: Muti-threading
 

While it might be cool, interrupts seem capable for the tasks we need to do. Threads would probably just complicate things, and while I doubt I'd use them, I don't really care if they are there and someone else wants to...

Re: Muti-threading
 

Since the current controller supports timer interrupts, you could code a simple OS to do pre-emptive multi-tasking and have prioritized threads that way.

Really, I doubt anything is stopping you, other than having capable programmers to be able to deal with concurrency issues. I wouldn't however make threads available by default though. With 6 weeks to build, I know that I would much rather spend my time getting the robot working rather than fighting with concurrency =).

Which means my vote is for keeping them the way they are.

Re: Muti-threading
 

Threads are overkill, right now, for what we're doing. Ask this question in a few years, and I might have a different answer for you ;-).

For now, I think adding threads just adds needless complexity to the coding, we already only have a day to actually test programming, let's keep it as simple as we can.

Re: Muti-threading
 

As a way to approximate multiple threads, we use multiple finite state machines. One for the tracks, one for the arm, one for the wrist, etc. Each one gets called every pass through the main loop. It allows multiple threads of conciousness without the overhead of task switching. It does take a bit more thought to come up with the state machines and the coordination mechanisms.

Re: Muti-threading
 

It would be cool, but it complicates programming. Even on PCs, this is true.

Re: Muti-threading
 

Personally, I dislike the idea. I was working with threads on my FIRST Editor project, and it's very unsafe. You have to make sure the thread is closed (securely), or else there will be many problems arisen.

Picture this: 10 seconds left of the 2nd finals match, and you're 1-0, score is 40-5 your favor. Then, at 5 seconds, your robot which was supposed to close a thread, didn't. Robot goes *POOF* into a big flame.

Even if FIRST, IFI, and whoever is our supplier next year saids they made it to where the threads close safely all by themselves, there's never a 100% chance that it will close safely.

I dunno, I just feel it's more trouble than it's worth. Not to mention the fact that a lot of things would have to change.

Re: Muti-threading
 

What I said. it would be cool, but I would probably just use one thread because of the complexities.

Re: Muti-threading
 

Whats to prevent you from implementing software threading now? Absolutely nothing at all. If you really feel you need threading ,then write yourself some threading. On an architecture this small, the overhead of full threading capabilites usually outweighs the benefits of threading.

I personally do not think threading is necessary at this point. If at any point it were necessary, then i would say write your own. We implemented a few processes that ran in the background, but i would hardly call it threading.

Re: Muti-threading
 

I'm considering it. Or at least a psuedo-threading that would appear to the "threads" as either a pre-empitive or cooperative threading environment. I know that the RC has enough power to handle the threads. The RCX from LEGo Mindstorm uses a chip with similar specs and that handles threading fine. I was just curious on people's opinions. :)

Re: Muti-threading
 

Perhaps implemented by a vector of callback function pointers, itinerated by an interrupt loop?


Pre-emption won't be much of a possibility, but doing little chunks of code would be possible.

Re: Muti-threading
 

KISS

You have something that works now, don't you? Why pour hours time and effort into something that wont really give you that much of a reward. For what we are trying to accomplish, a single thread that handles all of our robots checks and balances is enough. Also, by doing this, you are just creating more possibilities for something to go wrong, whether in testing or in the heat of battle.

Although it may be a good learning experience to play around with multiple threads or any other complex program idea you have, I would advise you to keep to that kid tested, engineer approved saying "Keep it simple, stupid"

Re: Muti-threading
 

Plus, many programs in PCs only use 1 thread.

Re: Muti-threading
 

Writing preemptive multitasking on the PIC seems to me to be a difficult exercise - you would essentially have to create an OS for it, as the 'os' would always have to be in control of the program counter and be able to save and restore the stack at any time. Plus we don't have much space to work with...

Re: Muti-threading
 

Better than doing it on last year's!

Re: Muti-threading
 

True... :D