• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1757 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

US_delay with Timestamp_get32();

Vincent St-Pierre
Intellectual 605 points
Other Parts Discussed in Thread: OMAP-L138, SYSBIOS

Hello all,

I need to have more information about the Timestamp_get32. I use this to make a US_delay just like this:

void US_delay(uint32_t usec)
{
     volatile int32_t i, start, time, current;

     for (i=0; i<usec; i++)
     {
          start = Timestamp_get32();

          time = 0;

          while (time < 350)
          {
               current = Timestamp_get32();
               time = current - start;
          }
     }
}

I want to know what happen if I'm calling US_delay(200) and I got a more priority interrupt that come for exemple at 120us in the 200us? Did the more priority interrupt will get the DSP process or the function US_delay will finish first and after the interrupt will get the DSP process?

I'm using a OMAP-L138 with SYSBIOS 6.33.04.39.

Thanks

  • 0
    TI__Guru* 96960 points

    Hi Vicent,

    If a higher priority interrupt comes in, it will preempt the lower priority thread. Note the Timestamp_get32 on the DSP on the OMAP-L138 just returns the contents of the TSCL register.  The Timestamp_get64 call returns the TSCL and TSCH values.

    Todd

  • 0 in reply to ToddMullanix
    Intellectual 605 points

    Hi Todd

    Ok good this is for interrupt but for task, I suppose that I can't use this function in a task because this will block to go to a priority task?

    thanks

  • 0 in reply to Vincent St-Pierre
    TI__Guru* 96960 points

    SYS/BIOS is a preemptive RTOS. If a higher priority thread (Hwi, Swi, or Task) is ready to run, it will preempt a lower priority thread. You might want to look at the timer module. Using a timer might be better if the required delays are not too small. If the delay is required in a Task, have the timer function post a semaphore that the Task is pending on. If the delay is in a Swi, have the timer function post the Swi.

    Todd

  • 0
    Intellectual 330 points

    Vincent

    I use a Hwi triggered by a GPIO interupt to detect a button.

    In the Hwi_function, I disable the button interupt and I start a Timer the I post a Swi.

    The timer is defined as a static RTOS object set to 25ms started by the user.

    The timer_function is then called upon timeout (25ms) and it simply re-enables the button interupt.

    I have mix emotions with using interupts on buttons. Keep in mind that they bounce both when pressed and when released. In the above example, if the user holds the button for longer than the 25 ms, if it bounces when released, it could trigger another unwanted interupt.

    I now either add a capacitor or I prefer to use a periodic swi to scan all of the button states.

    I hope this helps.