Multi-Threading

[Ted's]

First of all you have good English. We are talking about one led fading in and out which is being repeated. Imagine a flashing led. Now imagine the led is on. Imagine it not being on instantly but having an increase in brightness. Then imagine it having a decrease in brightness. Increase and decrease amount to flashing time. It softens the led's appearance.

Is that one led or 255 leds or fading while doing other stuff..... I think I speak for more people than myself when I say "hmmm confused"..

[skimask]

Is a 16f628a + pbp capable of multithreading? Is it capable of letting a led flash while proceeding another task to symbolize that it is busy?

You know and I know, based on previous performance, that nobody, anywhere, not today, not tomorrow, not ever, will be able to answer your questions to your satisfaction nor will you heed advice given to you by others...

But just in case....

No, PICs are not capable of multi-threading. None of them are. Period. Case closed. PICs cannot complete the execution of more than one single cycle instruction at any given time. Read it, learn it, live...
PC's up until about 10 years ago were never capable of multi-threading or multi-tasking as we think of the process today. They all used interrupts (either hardware or software) to switch tasks and/or memory space quickly enough that it seemed like they were running more than one program at a time.

It is very easy to, as you put it, fade and LED in and out, while running another program in a main loop, using interrupts. If I had a video of it, I would show you 20 RGB LEDs connected to a PIC18F8720, all doing something different, fading in/out, changing color, and so on and so on, while at the same time, displaying various debugging messages on an LCD, reading a 5 button keypad, reading a light 'program' from an SD card, communicating over a CP2103 USB link, and so on. All done with interrupts...not multi-tasking/-threading. All because it was being done so fast that it appeared to all be done at once. Slow down the oscillator speed to something very, very, slow and a person would be able to see (thru an ICD) the program executing different loops of code at different times.

That should be clear enough...but you'll probably refute every statement made above...and I'll probably 'un-refute' you at every turn....

[Ted's]

skimask, I recommend to you to read the other posts and my replies.

To me an interrupt means:

-Stop the current main program.
-Execute the interrupt routine
-Go back to where you came from in the main routine.

Basically interrupts should show a possible way to create the impression of multithreading. But.

But imagine there is a servo motor. The motor needs a signal every 20ms to keep it's torque. So the interrupt starts the interrupt routine. The interrupt routine should take say 2 seconds. And within these two seconds there is the action of force onto the motor.

This is what I was alluding to when writing about the pauseus issue. This stands for reserving time within the interrupt routine.

Or do DT's includes make the pic execute the code (even the main code) by cycling through each interrupt each cycle of code execution? So using a 20Mhz quarz leads to processing a portion of each code every 0.2 us?

I appreciate that you want to answer my questions to my satisfaction. Then give me a code example showing how to do that with DT's includes.

[skimask]

skimask, I recommend to you to read the other posts and my replies.

Hey, Good Idea! Why didn't I think of that....

To me an interrupt means:

-Stop the current main program.
-Execute the interrupt routine
-Go back to where you came from in the main routine.

Basically interrupts should show a possible way to create the impression of multithreading. But.

So far, so good...

But imagine there is a servo motor. The motor needs a signal every 20ms to keep it's torque. So the interrupt starts the interrupt routine. The interrupt routine should take say 2 seconds. And within these two seconds there is the action of force onto the motor.

This is what I was alluding to when writing about the pauseus issue. This stands for reserving time within the interrupt routine.

Or do DT's includes make the pic execute the code (even the main code) by cycling through each interrupt each cycle of code execution? So using a 20Mhz quarz leads to processing a portion of each code every 0.2 us?

You're thinking too linearly...stuck inside a box.
Keep track of a timer/counter that gets tipped much faster than every 20ms. Hit the servo, wait 20ms later (and servo's don't NEED exactly 20ms), hit the servo again.
If those LEDs I eluded to earlier miss a pulse completely, I'll see flickering. If one of those pulses is just a bit off, I most likely won't see anything...but quite frankly, they're solid, nice and smooth. So, from THAT programming standpoint, there isn't much of a difference between LEDs and Servos. Interrupts work great for me and a load of other people. You aren't any different.

I appreciate that you want to answer my questions to my satisfaction. Then give me a code example showing how to do that with DT's includes.

I don't want to. Just making a point based on your last 'thread' (if we can call it that)....
And it's YOUR job to give US a code example of how to do anything with DT's Instant Interrupts...and WE will HELP YOU figure out why it doesn't work the way YOU want it to work.
And what's wrong with the examples in the instant interrupt threads?

[Darrel Taylor]

And what's wrong with the examples in the instant interrupt threads?

I'd like to know that too.
<br>

[Jumper]

So we have one led you want to flash in a fading way.

How frequently do you want to flash it?

Do you want to do other stuff while flashing the LED? In that case what will the PIC do?

Can you put the LED on PORTB.3?

How fast do you want to fade it up and down?

How smooth do you need it, how many steps would you like the led to have on the way up and down?


Before we even try to untangle the code for this it would be nice to know that you can use this pin and get the other information as well.

/me

[skimask]

Can you put the LED on PORTB.3?

I'd doubt it...
http://www.picbasic.co.uk/forum/showthread.php?t=9275
Check post #32 and #33!

[Ted's]

Jumper if you want to design a code example do not stick to values, stick to variables instead. Frequency should be f. Other concurrent thread(s) exist while fading in/out. There is no data available about them yet. Just use "LED", I'll use a pointer to the right port like LED VAR PORTX.Y. Speed of fading should be a function of frequency. Freqency means: every 1/f seconds there is a change. If LED is off, Led_fade_routine starts and vv. Led_fade_routine consists of fade_in_time = 2/f and fade_out_time = 2/f. Smoothness depends on OSC. Should be as smooth as possible, ie chunks_duration should be at a minimum.

Thanks for your initiative. I appreciate that.