RTOS/TM4C1294NCPDT: Proper way to pass argument to HWI

svl123 said:

I think that I am not passing the variable to the ISR correctly. What is the proper way of doing it?

You don't. Think about it, how would the hardware know what to pass?

What is it you are trying to do?

Robert

Hi Robert,

I want a program that will set the LED to on or off based on the value of a variable every time the timer expires.

OK.  Remember when you were told never to use globals? They oversimplified.

In an RTOS you might use a queue or a semaphore. Although they would still be globals they have some protection. In you simple case a simple global int will work. One think to keep in mid is that writes must be protected so that they are not interrupted by the read partway through. On this architecture, that's not an issue with ints since the write cannot be interrupted.

Robert

Ok, I can use a global variable. How does the "Argument passed to isr function" field work, then? Will it only accept a constant value?

svl123 said:

How does the "Argument passed to isr function" field work, then?

What argument passed to isr function field???

Robert

The "Argument passed to the Timer ISR function" field in "Additional settings."

I copied/pasted a picture and it did not appear - if you opening the project .cfg file and using the GUI (not the script file) brings up a page called Timer - Instance settings. In this page there is a subsection "additional settings" which contains a field "Argument passed to the Timer ISR function." What is this for?

I have no idea what you are talking about. It sounds like some sort of RTOS configuration tool in which case it probably has to do with the RTOS timer, not the micro timers.

Robert

Yes, it is an RTOS configuration tool. I'll just do as you suggested, thank you.

When you create the a timer in TI-RTOS, you can specify an arg. For example to create it dynamically:

Timer_Params timerParams;
Timer_Params_init(&timerParams);
timerParams.period = 100000; /* 100,000 uSecs = 100ms */
timerParams.arg = 5;
Timer_construct(&timer0Struct, Timer_ANY, (Timer_FuncPtr)timerFunc, &timerParams, NULL);

Here's the timer function that takes the arg as a parameter. This allows you to use the same timer function for multiple timers.
Void timerFunc(UArg arg)
{
...
}

You can create the timer in the .cfg file also.

Note: by default the kernel creates a timer to drive it's clocking (e.g. Task_sleep, Semaphore_pend with a timeout, etc.). The kernel has the Clock module that you can plug functions into. This removes the need to create your own timer. Of course, the periods you want must be a multiple of the Clock modules timer (which by default is 1ms...but you can change it).

Todd

Todd,

Perhaps you can assist - poster's subject line notes: "Pass argument to HWI."     (Hardware Interrupt assumed)

Yet - where is the "beef" (hardware) - instead he seeks to, "Pass an argument" - the (only) hardware which I note is 2 passive Leds - which are controlled via entry into what appears to be a (strict) "value or software based interrupt!"      Any/all hardware appears "incidental" at best - absent at worst.

Might you (kindly) clarify - fill in the blanks.     (what hardware?)       Merci...

To supply an arg to an Hwi is basically the same. When you create the Hwi, there is an arg field in the Hwi_Params structure that can be specified. When that interrupt is asserted, the kernel calls the user supplied function (supplied in the Hwi_create or Hwi_construct) along with the arg.

For more details, you can refer to the SYS/BIOS (TI-RTOS kernel) API reference. For example in ti.sysbios.hal.Hwi you'll see this sample code:

Thanks for stepping in Todd.

So HWI are managed interrupts and the actual hardware interrupts are what we've seen referred to as the (badly named) zero latency interrupts?

Robert

Not quite. An Hwi in the kernel can be managed or unmanaged (we call this a zero-latency interrupt). We've debated the name "zero-latency" quite a bit:) When you create a zero-latency interrupt with TI-RTOS, the kernel adds no extra latency to the ISR and it never disables them...thus the name zero-latency. Be careful with zero-latency interrupts though. You cannot make any kernel calls that impact scheduling (e.g. Semaphore_post, Task_setPri, etc.). Of course for certain real-time applications, a zero-latency interrupt might be required (e.g. C2000 application use them all the time when dealing with motor control).

Basically when you are using TI-RTOS, the kernel needs to be aware of all interrupts (both managed and unmanaged/zero-latency) in the system. This is different that just using driverlib or FreeRTOS. Here you plug the vector table yourself and manage accordingly.

Todd

Thank you for your replies - I ended up just using volatile variables declared outside of the main() loop and not passing anything into the HWI itself.

-svl123