Re: [Xenomai-help] Execution error with rtdm heartbeat example

[Jean-Luc Pamart <jlpamart@domain.hid>]

Jan Kiszka a écrit :
> Jean-Luc Pamart wrote:
>   
>> Jan Kiszka a écrit :
>>     
>>> Jean-Luc Pamart wrote:
>>>  
>>>       
>>>> Hello
>>>>
>>>> I  try to execute the heartbeat example (xenomai 2.3 with kernel 2.6.19)
>>>> With the unmodified sources when the heartbeat module
>>>> is being unloaded (rmmod)  I obtain :
>>>>
>>>> atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
>>>> access hardware directly. 
>>>> and the unloading can't be finished.
>>>>
>>>> I try to slightly change the sources. It works with no bad kernel
>>>> message and
>>>> complete unloaded with this modification :
>>>>
>>>> void heartbeat(void *cookie)
>>>> {
>>>>                while (!end) {
>>>>               ...
>>>>         }
>>>>     set_leds(0);
>>>>     }
>>>> void cleanup_module(void)
>>>> {
>>>>     //  set_leds(0);
>>>> } 
>>>> My interpretation :
>>>> In the non modified example, We try to access directly to the keyboard
>>>> after the end of the rt-driver(after 
>>>> rtdm_task_join_nrt(&heartbeat_task, 100);)
>>>> So it is a problem for the kernel.
>>>>     
>>>>         
>>> Hmm, the problem might be that set_leds(0) gets preempted. Could you try
>>>
>>> local_irq_disable();
>>> set_leds(0);
>>> local_irq_enable();
>>>
>>> for cleanup_module()?
>>>
>>> Yes, this demo accesses shared hardware directly, and that can confuse
>>> Linux or cause even worse situations. Moreover, this high-prio task also
>>> causes fairly high latencies. So it is nothing for serious use anyway.
>>> But if we can improve obvious issues, there is no need to hesitate.
>>>
>>>  
>>>       
>>>> Is it a good interpretation ?
>>>>  
>>>> what is the difference between rtdm_task_join_nrt(&heartbeat_task,
>>>> 100) and
>>>>  rtdm_task_destroy(&heartbeat_task) ?
>>>> What is the role of the polling argument (value 100) ?
>>>>     
>>>>         
>>> Not being too lazy to answer, but I would like to know if the doc is
>>> improvable: Did you read the API documentation [1]?
>>>
>>> Jan
>>>
>>> [1]http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__rtdmtask.html
>>>
>>>
>>>   
>>>       
>> Hi
>>
>> I don't want to use this example for a real application.
>> It's only for the "fun" : I' ll have to write a rtdm driver
>> so now, I study ...
>>
>> That's was a good proposition for the heartbeat module :
>>
>> void cleanup_module(void)
>> {
>>    end = 1;
>>    rtdm_task_join_nrt(&heartbeat_task, 100);    local_irq_disable();    
>> // to be added
>>    set_leds(0);
>>    local_irq_enable();     // to be added
>> }
>>
>> 1 / it run as usual very well
>> 2/ his unloading can finish
>> 3/ his unloading doesn't anymore cause  "Spurious ACK .."
>> so all is all right now !
>>
>>     
>
> OK, good know. That experiment was just to check the theory, I will
> actually commit your first proposal as fix (call set_leds before leaving
> heartbeat()). It's shorter.
>
>   
>> But, this problem appears only when unloading the module.
>> After all, set_leds() is used by heartbeat() without any problem.
>> Why not in cleanup_module() ?
>> Sorry it's perhaps an obviousness but not for me.
>>     
>
> The difference between the RTDM task function heartbeat() and
> cleanup_module() is the execution context: the former it RT, thus cannot
> be preempted by any Linux activity, the latter is a Linux task that is
> preemptible by Linux interrupts or other Linux tasks, including other
> keyboard-using code.
>
> Actually, all this is only true for single-processor systems. SMP will
> cause troubles due to the unsynchronised HW access of Linux vs.
> hearbeat. Anyway, this remains an imperfect demo.
>
>   
>> I have red the rtdm_api.pdf doc which is embedded with the Xenomai sources.
>> I'd like to try "hello world examples" for a more large point of view
>> and some easy begining you haven't when you read the documentation :
>> a list of functions and a brief use - too short for the beginner i am -
>> Well, it's the same situation (it's my point of view, perhaps I am alone
>> ??)
>> when you try to write a letter in a unknown language :
>> the dictionnaries are good for spelling not for grammar (construct of
>> the sentence).
>>     
>
> Yep, I understand and agree. Still, writing appropriate introductions
> for all this, either as text or in form of thoroughly worked out
> examples, takes quite some effort (means: time).
>
> Therefore, the best would be if some former beginners help us by filling
> gaps in the existing documentation and/or examples repository. Fixing
> remaining glitches in their contribution is not a big problem (see e.g.
> how the RTnet docs started on xenomai.org). The point is that we would
> then already know where to invest required effort effectively. 
I work for a school project "systeme de vision artificielle pour 
prétailleuse" : a tractor which cut the vine of Champagne
(the famous drink ...)
The embedded application will analyse the movies in real time and lead 
the cutting part of this machine (with a CAN-BUS).
I have to write a driver which interface a PCI board (connected to a 
little camera) and ask
Rodrigo Rosenfeld Rosas for a squeletton of his driver.
So, I think I have now a beginning ...
In the future, if the project is finished, I can send the whole driver 
to the xenomai-forum
with, (if you find that interresting) some explanations (from a beginner 
point of view)

> Keep in
> mind: individual project contributors don't scale infinitely, thus the
> team size need to.
>
>   
Do you mean that there isnt enought contributors or the team whant to be 
bigger ?


>> So for the differences between rtdm_task_join_nrt and rtdm_task_destroy,
>> what I understand :
>>
>> 1/rtdm_task_destroy(&heartbeat_task)
>> Stop and destroy immediately the target task.
>>
>> 2/rtdm_task_join_nrt(&heartbeat_task, 100);
>> Wait for the end of target task
>> It is the user to take care of the termination of the target task
>> If not, rtdm will never return
>> (the task must cooperate)
>>
>> Ok but what is "polling delay" for ?
>> At the first look I think about a watchdog but it's not the case
>>
>> Sorry for these obvious issues !
>>     
>
> No need to apologise, specifically as that "polling delay" is in fact
> badly documented. rtdm_task_join_nrt() may wait on the termination by
> periodically checking (polling) the RT task state. So the delay defines
> this period. Will fix.
>
>   
Ok it's clear now :
some of the fonctions are in rt context and the others not and especially
the interface with insmod, rmmod etc. obviously in user mode.


>> BTW, the "real-time" answers of this forum is impressive : bravo !
>>
>>     
>
> I think this is mandatory for real-time projects, isn't it? ;)
>   
yes !

> Jan
>
>