Hi,
I happened to be confused about signaling a semaphore in an interrupt
handler, like doing rt_mark_stack_mgr in any ethernet driver of RTnet.
Will the interrupt handler be preempted by the task waken up from the
semaphore waiting queue? To make it clear, I added rtos_print("A") before
the rt_mark_stack_mgr and rtos_print("B") after, and rtos_print("C") in the
do_stacktask(). The result turns out to be A, C, B. So the interrupt handler
is preempted, which is not as I expected. For this, I would like to know
your idea.
BTW, My colleague student said, it is possible to give the interrupt a high
priority, higher than the real-time task, so it will not get preempted. Is
that true?
For the Firewire, I have build the rtos_tasklet_scheduler, which runs the
linux tasklet in a real-time way. So this is useful in the case of Firewire.
The idea is same as the stack manager. But since the Firewire should be
connected to RTnet, which means the rtos_tasklet_scheduler and the stack
manager should coexist, they need different priorities. I think the
priority of rtos_tasklet_scheduler should be higher. Then the question again
comes out: shall the rtos_tasklet_scheduler be preemptable? If not, how to
prevent that?
Currently, I am working on porting the eth1394 module to RTnet. The eth1394
has its own header building functions, like hard_header, rebuild_header,
etc, which may slightly increase the workload for porting. Hopefully, I can
run the first rtping on Firewire before this weekend-:). Btw, I think RTnet
only uses the hard_header, why other header functions, like rebuild_header,
hard_header_cache, etc, are not important?
Looking forward to your reply.
Best regards,
Zhang Yuchen
MSc Student
Control Engineering Group
University of Twente
The Netherlands
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
RTnet-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/rtnet-developers
