This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

led is not blinking whiel simulation

#define ledon IO1SET
#define ledoff IO1CLR

void EDF_scheduler(void);
int main(void)
{ IODIR1 = 0x00FF0000; scheduler();
}

void scheduler(void)
{ while(1){ int i,time=0; int curr_process=0; while(time<sim_time) { if(curr_process > -1) { if(array[curr_process].ceu < array[curr_process].wcet ) { array[curr_process].ceu++;
if((array[curr_process].task_id )==1 ) { here i want to blink led ledon = (1<<16); // Turn ON P1.16 – P1.23 delay(900000); ledoff= (1<<16); // Turn OFF P1.16 – P1.23

}

if((array[curr_process].task_id) ==2 ) { ledon = (1<<17); // Turn ON P1.16 – P1.23 delay(9000); ledoff= (1<<17); }

Parents
  • So you didn't take the time to fix the part of the code you were told about?

    ledon = (1<<17);  // Turn ON P1.17
    

    ledon = (1<<18);  // Turn ON P1.17
    


    Two different assigns but same comment. Should teach you to use magic numbers when you could instead make use of enum or #define to actually name your pins, thereby removing the need for a redundant (and in your case broken) comment.

    ledon = (1<<21);  // Turn ON P1.16 – P1.23
    


    You still think a single bit assign affects 8 processor pins?

    void  delay(int x)
    {     unsigned  int  k,l;
          for(k = x;k > 0;k--)
          for(l = 0;l < x;l++);
    }
    


    Try and google a bit about this type of busy-looping delays. You might find out that they aren't so very good to use. There are just on this site at least a couple of hundred threads debating the problems with compiler versions, optimization etc.

    delay(900000);
    
    delay(9000);
    


    A factor 100 difference in parameter between these two calls. Haven't you made specific tests to find out what actual delay you get when you call that delay() function?

    Next thing. Standard debugging is done by simplifying problems and figure out which half of the problem that isn't working. So ignore all your code simulating tasks. Do you manage to light a single LED if that is all you try? Do you manage to turn off a single LED? If that works, then you know the LED code is good and can settle for figuring out if your delay() code is working. And if your code that decides if you should blink the LED is working or not.

Reply
  • So you didn't take the time to fix the part of the code you were told about?

    ledon = (1<<17);  // Turn ON P1.17
    

    ledon = (1<<18);  // Turn ON P1.17
    


    Two different assigns but same comment. Should teach you to use magic numbers when you could instead make use of enum or #define to actually name your pins, thereby removing the need for a redundant (and in your case broken) comment.

    ledon = (1<<21);  // Turn ON P1.16 – P1.23
    


    You still think a single bit assign affects 8 processor pins?

    void  delay(int x)
    {     unsigned  int  k,l;
          for(k = x;k > 0;k--)
          for(l = 0;l < x;l++);
    }
    


    Try and google a bit about this type of busy-looping delays. You might find out that they aren't so very good to use. There are just on this site at least a couple of hundred threads debating the problems with compiler versions, optimization etc.

    delay(900000);
    
    delay(9000);
    


    A factor 100 difference in parameter between these two calls. Haven't you made specific tests to find out what actual delay you get when you call that delay() function?

    Next thing. Standard debugging is done by simplifying problems and figure out which half of the problem that isn't working. So ignore all your code simulating tasks. Do you manage to light a single LED if that is all you try? Do you manage to turn off a single LED? If that works, then you know the LED code is good and can settle for figuring out if your delay() code is working. And if your code that decides if you should blink the LED is working or not.

Children