juanba romance wrote: > Hello all, i am re-writing a old linux driver which i did myself some > time ago, cause i am in charge to provide a RT system framework. This > is one of the first steps so i have followed the RTDM model to do the > stuff. > Now i also have enough time to change its ugly capabilities/defects > but i am a little stuck right now.. > > I would like to improve my previous design fully buffering the > incoming user data flow on write method so a input FIFO it's planned. > The FIFO will be emptied using a rt-task created from the "open" > procedure and signalled from the "write" method before the user flow > exit. The point is: > where the FIFO handler references should be defined ? > > I have take a look to the serial driver 16550 and my code is really > biased by its data device definition strategy ( obviously this is my > first RTDM monster ;-) and i need some guide ), instead of my > proposal, its design empty the TX FIFO from the IRQ service stuff > where the user context was passed as argument at the "open" call, so > all the parts are softly linked.. > > I would prefer to add the above program capability to avoid rewrite as > much as possible the current ISR symbol. > but i don't know the beast strategy to be applied to overcome the . > > I have pass the "context" field dev_private area pointer to the > rt_task "by hand" but its value is really weird. Should this kind of > information be defined globally trough the "static" stuff and pass > this argument to the rt_task_init symbol
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? 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. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
