Gui timer v/s Async timer priority

[mowgli]

Hi NI,

I am trying to build an application where in i am communicating with an automotive ECU over RS-232 periodically. I am using an aysnc timer to do the communications part and a GUI timer to do the graphical object update. I have three questions for your team.

1. What RTOS and PC configuration do you recommend for using a RT Async Timer with Prority ? (preferably whats available in the market today in terms of "cheap" hardware)

2. What is the priority of the GUI timer when compared to the Async timer? Is is possible for the GUI timer to inetrrupt the Async timer fucntion call ? If yes...is there an exclusion mechanism that would stop this from happening ?

3. I am using a two linked list concept...the first list populates while the other's data is being drawn on the strip chart...and then i flip over to populating the second linked list while the first lists data is being plotted. The communications(population of data in a structure in a linked list) is being done in the Async thread while the plotting is being done in the GUI thread. The issue i am facing is that i do not have a clean linked list population, plotting and freeing of data sequence...i feel this is due to some un-predictability in the timer function calls.(hence Q2 above). Do you recommend only using thread safe queues or do you think this is do-able with linked lists.

Looking forward to your reponse.

-Ashish

[ebalci]

Hi Ashish,

What do you mean by RTOS? A Real Time Operating System?

If so, what type of GUI are you talking about?

To my knowledge, the GUI timers are only available for Windows environment, which is not real-time.

So, RT Async timers are not available for Windows.

I could not understand how these two timers (GUI and RT Async) came together.

Provided that we overcame this ambiguity, I would prefer you to use thread-safe queues (TSQ).

Good thing about TSQs is that you can assign a callback to run, say, when there is N number of bytes in the queue.

Create just a single thread for communication with the ECU.

So your comm thread fills the queue and before it is completely full, the TSQ callback fires and empties it by plotting its contents.

This structure looks much simpler and robust to me.

Let us know what you think.

[mowgli]

Hi,

The "RT NewAsyncTimerWithPriority is available only on real-time operating systems" line got me a bit puzzled so i asked the first query...however i understand now that the RT Async Timers are not available with windows...so thats quite out of debate...thanks for your inputs on this.

I was using a GUI timer and an Async Timer(NewAsyncTimer) for doing two things...the GUI Timer did the update on the graphics objects  (strip charts etc.) while the Async timer did my RS-232 communications(so that GUI effects had no effect on the RS-232 send/receive)...i was under the impression that both these would be independent threads with a known priority...so that way i could know up to a point a fixed calling and execution sequence...so that was the second question...i observed that the two function calls were not prioritized...so the GUI function call could fire in the middle of the Async function call...please corect me if i am wrong

I will try the TSQ's as you mentioned...will get back to you shortly with my analysis...i guess the example for TSQ's is available with the labwindows documentation.

[ebalci]

I don't know what degree of certainity you need but a "fixed calling and execution sequence" is just a dream in a Windows environment.

Windows will operate your threads together with many more of its own, all with varying priorities.

So, you should think of priority as a vague way of making one thread to be operated more/less than another lower/higher degree thread.

No thread priority class guarantees a certain frequency of thread execution.

GUI timer callbacks are executed in the main program thread while async timers are executed in a seperate thread.

So, yes their execution times may coincide. Hence the need to protect your global data.

Data accessed by multiple threads should be protected so that, no thread would be interrupted in the middle of a write/read operation on that data.

TSQs do that for you. Otherwise you cannot be sure about the integrity of the data you are plotting.

If you need do some more reading about this. But TSQs stand out as a more elegant way to solve your problem.

[mowgli]

We have implemented TSQ's and it seems to solve our problem. I thank you for your quick support.

Question related to the TSQ example in the LabWindows environment:

If i want a read/write thread to fire every say 50msec(or X msec in general) using the TSQ mechanism example, how do i modify the "delay" call in there to make the thread for reading/writing periodic ?

Is there an elegant way to do this using the TSQ thread pool call in the example ?

-Ashish