Compiler/TM4C1294NCPDT: TM4C: Is timer construct and function treated as TASK, correct, so it okay to run a semp.

It needs to be stable accurate 1mSec.

However when I use semaphore timeout with 10, then I do not need a timer in HWI to fire the semaphore where it can self fire itself. The simple solution is to remove the semaphore post from the timer code.

Is this right approach?

Hi Richard,

What exactly are you trying to do? You could simply use Task_sleep in RFD_Sem_Task_System(). In this case, you don't need the semaphore or the Timer instance since the sleep is based off the Clock modules timer. 

Todd

Thank for the suggestion about Task Sleep, however, I do have other semp post from command interface from other part of code so I leave semp pend, (but again that can be further changed)

This loop code is part of the operation sequencer which now runs every 10mSec checking flag to process application tasks. 

It now running correctly when I remove semp post in HWI code, it indeed a mistake. 

I little confused about HWI and SEMP (TASK)

I have GPIO interrupt callback, are they HWI?, if so this means I cannot post a SEMP, right?, how to post SEMP from GPIO event?

I do have GPIO interrupt callback that post semp, it has BIOS_WAIT_FOREVER on Semp pend statement. It seems to work fine. 

Richard, are you trying to dispatch your action every 10mS?

If so, and in the likely event you have not run out of hardware timers, might I suggest you use an actual timer rather than a software timer? That will give you stability close to the microprocessor clock stability.

Also it is conventional wisdom that 1mS produces too high an overhead for the clock. That's a your milage may vary situation though and should be less of an issue on most ARM cores than smaller processors.

Robert

Yes, 1mSec come from Timer4 I deleted the Semp post from there, it was a mistake. This is accurate for 1msec tick number to measure the performance of the system and LED sequencer. 

The sequencer task body now run 10mSec via Semp pend timeout every 10 mSec which is good enough. I could use spare timer and run 10mSec this way rather than Semp or Task_Sleep. Should I do that?

------------------------

So GPIO interrupt (and timer interrupt?) is permitted to use Semp Post because they not HWI, correct?

Below is a callback example (about 30mSec event)

void RFD_AD7175_RCV1_DataReadyFx(unsigned int index)
{
//---------------------------------------Debug Timing
GPIO_toggle(EK_PL4_EXP4_TIMINGPIN);
//---------------------------------------
GPIO_disableInt(EK_PQ1_SDI0_DRDY);
Semaphore_post(RFD_RCV1_ADC24Data_sem_handle);
//---------------------------------------Debug Timing
GPIO_toggle(EK_PL4_EXP4_TIMINGPIN);
//---------------------------------------
}

richard payne said:

could use spare timer and run 10mSec this way rather than Semp or Task_Sleep. Should I do that?

I won't say should. It is an alternative. The advantage is a single interrupt every 10mS with accuracy as good as your crystal. The disadvantage is you are using another hardware interrupt. If your timing is tight though, it's a real alternative.

richard payne said:

So GPIO interrupt (and timer interrupt?) is permitted to use Semp Post because they not HWI, correct?

If I understand the terminology used then it is a HWI. The interrupt will be restricted to a subset of RTOS functions normally. OTOH if you are doing small actions, like changing pin state then you can complete it entirely within the interrupt. Small is user defined.

Robert