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
>
>
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
