AVR Freaks

I don't think you even need the 3 timers:

    while (1)
    {
        if (Timer_Flag == 1)
        {                        
            Timer_Flag = 0; 

            //increment timer every 10ms
            Timer1++ ;

            if ( Timer1 == 10 ) // check if time is 100ms
            {
                Timer1 = 0; 
                switch (STATE)
                {
                case STATE1 :    // 1st 100ms - update LED1
                                 LED1 =~ LED1 ;   // change state of LED1
                                 STATE = STATE2 ; // Move to next STATE
                               break;
                case STATE2 :    // 2nd 100ms (ie, 200ms) - update LED2
                                 LED2 =~ LED2 ;   // change state of LED2
                                 STATE = STATE3 ; // Move to next STATE
                              break
                case STATE3 :   // 3rd 100ms (ie, 300ms) - update LED3, then restart the cycle
                                LED3 =~ LED3 ;     // change state of LED3
                                STATE = STATE1 ;   // return to STATE1
                              break;
                }
            }

}
 

I think they are two terms to describe the same thing.

Cooperative Multitasking means that individual tasks routinely give up control of the CPU when they don't need it. Usually while they are waiting for some external, to them, event. So they might be waiting on a semaphore; they might be waiting a period of time before they need to run again, or they might simply yield() to give other tasks the chance to run.

Cooperative Scheduling means that the piece of software which decides when each task should run, and which handles semaphores, mailboxes and the like, assumes that all the tasks are coopertive.

The two things go hand in hand. There's nothing to stop you writing a task which doesn't cooperate; one which waits on an external event with a 'while(FALSE==event)', but if you do then there's nothing the scheduler can do about it.

Yes.

Multitasking just means having multiple tasks.

If you have multiple tasks, you have to decide when to run each one - that's scheduling.

Again: https://www.rapitasystems.com/blog/what-are-co-operative-and-pre-emptive-scheduling-algorithms 

Lets begin with some basic terms, in order to have multi-tasking, one must first have a task!

A task is a sequence of instructions, sometimes done repetitively,
to perform an action (e.g. read a keypad, display a message on an
LCD, flash an LED or generate a waveform). In other words, it’s
usually a small program inside a bigger one.

The simplest form of multi-tasking is foreground/background tasking, this usually means one has a main loop where most of the processing is done (background), and an ISR(forground) that is triggered by some event, such as a timer interrupt, a character received via SPI or USART, or an external event like a pin change interrupt.

Two or more foreground tasks above would be an example of multi-tasking....

Here scheduling is handled by the interrupt priority mechanism built into the micro, and in this example that would be pre-emptive, not cooperative scheduling! 

Jim

edit: added scheduling, and pre-emption...

Thanks Andy for clarifying that, and just to add, tasks do not have to be ISR(), that was just one example, tasks can be "scheduled" to run as multiple background tasks as well.

There is a problem with that tutorial and it is this statement...

...what is described there is Run To Completion (RTC) scheduling which isn't really Cooperative Scheduling. A cooperative task is one that hands control (yields) back to the scheduler when it no longer needs full access to the CPU, irrespective of whether it has finished it's task.

A true cooperative task will, once it's running, live inside a 'while(1)' loop.

That's RTC (run to completion). 

State machines all the way. Their use in embedded systems ought to be made compulsory. Driving character LCDs is sooooo much easier when you use a state machine and a timer tick.

Ah, but the tasks have no say in whether they cooperate; they just do. In a true cooperative system a task will make a decision to yield to the scheduler.

Take waiting for a character to come in from a USART. In an RTC system the task will look at a flag variable set by an ISR and if it is not set all it can do is exit. The next time it run it uses a state machine to go back to the 'waiting for a character' state and retest the flag. Rinse and Repeat.

In a cooperative system the task can test a semaphore set by the ISR (and here's the important bit) and execution of that task will, to the outside world, appear to pause at that point. The task does not exit; it's all taking place in a while(1) loop. Meanwhile the scheduler has got back control and can schedule other tasks, handing control back to the paused task as and when those other tasks cooperate by given back the CPU. Rinse and Repeat.

The difference is conceptual. What makes more sense in a multitasking system when you are waiting for an external event? Abandoning what you are doing and coming back to it later, or waiting at that point until the event becomes true?

@OP - you really need to do some reading of proper resources about scheduling/mutitasking etc on small devices. Start with...

Intel Application Note AP-61

Adam Dunkels Protothreads

Intel Other Resources - Intel Vintage

[1/3 page]

Intel AP-61 Multitasking For The 8086

Protothreads versus State Machines « State Space by Miro Samek

Key concept: event-driven programming (Quantum Leaps)

[mid-page]

Event Loop & Inversion of Control