juanba romance wrote:
> Thanks Jan..
> On 7/30/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Before going into details on how to pass references between driver tasks
>> etc.:
>>
>> Why do you want to establish a dedicated task for transmission? Is the
>> job you have to perform there too heavy for IRQ context?
> 
> 
> The application has two issues related on:
> 1.- The transmission setup would be really time extensive, so the ISR will
> be really too busy sucking the data from the FIFO and pushing it into the
> chipset
> 2.- Due to system specifications, we have focused the ISR performance in the
> data reception flow, so the transmission irq context management must/need be
> really fast.
> We would like to hold as much as possible both features and this is the
> reason to evaluate the rt_task approach..

Ok, got it.

> 
> Keep in mind that such a task requires additional management (assign
>> reasonable
>> priorities e.g.) and adds further latencies. It's no magic bullet, but
>> it may be appropriate if there is actually a lot of work to do that
>> shall not block other, more important jobs.
> 
> 
> I mean the application specifications allow us to block a little bit the
> internal driver write capabilities but the isr read management should be
> inherently the most priority program flow.
> 
> Jan
> 
> 
> As I have mentioned in the previous mail the driver is also a formal design
> review, so lot of  variables and data addresses have been re-arranged and
> re-structured, one of their was the killer one cause was pointed to the
> hyperspace into the thread symbol..
> I have checked the context pass argument with the decoded one at the thread
> and all is ok now, no troubles related on.
> The writer thread is always coupled to the "context" area reference through
> the "open" call softly. Anyway, I think that a more generic question could
> be stated right now.
> 
> Could i assume that the memory references coupled with the context argument
> at the "open" call are stables along the context cycle life?
> I think that this is not any data trusting if i always link the thread
> creation/destroy to the "open"/"close" call entries, but i assume also that
> i could have a fully wrong picture about all this stuff.

If you create the task on "open", stuff its reference into the context,
maybe additionally pass the context as argument to the task function,
and then clean things up on "close", I see no problems of
stalled/inconsistent references. Problems may only arise from races
between the open/close and the task function. So make sure not to rely
on specific, only-valid-on-UP execution orders.

> 
> If you are so kind to give me any extra hints i would be really grateful
> Thanks a lot..

If things are not fully clear yet, I would suggest to post some code
now. That is far more efficient than just describing the design.

Jan