OpenAT 3/4 and tasks

Legacy Open AT
1

I would like to know if somebody have more information regarding tasks and OpenAT.

I have the following questions:

  1. If I use the basic OpenAT api I have access to 3 tasks. How is task synchronisation achieved? If two or more tasks want to access the same resource (e.g. global ram buffer), must I provide a re-entrant function? Or does the tasks execute within the same thread context, meaning no synchronisation necessary?
  2. If I use OpenAT ADL layer I only have access to 1 tasks. After subscribing to ADL services function callbacks give the execution context back to me.
    2.1) Do I need to provide synchronisation for shared resources? In other words will I receive callback’s from different services executing in two different threads at the same time?
    2.2) Is there any restriction on doing ADL function calls after I received the execution context via a callback function? In other words for example if I receive a SMS subscription callback, can I call any ADL function/subscription etc. within my callback function?

I think to summarise all of the above questions: Is OpenAT driven by a single execution thread? No synchronisation needed?

2

Hi truhann,
I am providing you the answers to your questions based on my experiences with Open-AT.

  1. The 3 tasks provided in Open-AT version 3 execute in the same context. You do not need to provide method for synchronisation. In other words, when one wm_apmAppliParser function for a task is executing, it cannot be preempted by another wm_apmAppliParser (of another task). Only after the wm_apmAppliParser (i.e. a task) exits will the other task be given a chance to execute. To verify this, you can make an application having a global shared resource. The appication should be such that in one of the task (wm_apmAppliParser), the applicaiton should get into an infinite loop until a particular value is set for the shared variable. The value which would get the applicaiton out of the infinite loop should be set in the other task. You will see that the other task will never get a chance to execute and module reset will occur (due to watch dog reset). This proves that preemption is not present and you do not have to provide for object synchronisation.
  2. In the same way, ADL too is single tasking execution system. When one callback function is in execution, another callback function cannot preempt it. Only after the execution of one callback function is complete, can another callback function start. Hence, here also you do not need to provide for object synchronisation. You will agree that this will reduce the complexity of the embedded application for sure.
  3. There is no subscription limitation as such in ADL. For instance, if you receive an SMS, you can definitely subscribe to other ADL services. However, it must be noted that applicaiton should be such that control returns to ADL library. The Open-AT applicaiton should not hog the CPU. This is because, if control does not returns to ADL library it will not be able to process other events (which might result in stack overflow as the callbacks which are to be executed will be stacked). Hence, the best way to perform very complex operations is through the usage of timers. When you use timers, the ADL library get enough time to perform its internal functions.

In a nutshell, you do not need to provide for object synchronisation in Open-AT. The architecture of Open-AT is such that it reduces the burden on the programmer and provides very simple and easy to use callback functionality to achieve the desired task.

Best Regards,

3

Thank you very much.

Response appreciated. I have written a couple of unit tests using the ADL layer and came to the same conclusion.

Regards