>> How could I
>> share this memory with userspace RT-programs in a deterministic way?
>Set up the memory mapping between kernel and user space during (non-rt)
>initialisation. This means that you have to create some mapping from the
>physical block into the user space address range. I think
>remap_pfn_range() or io_remap_page_range() should do this after mapping
>the physical memory into the address space of the kernel (ioremap()).
>But I suggest LDD3 on this topic as a better reference.
Of course. You are right. I will only need this at initialization so I
shouldn't bore about that.
>> I can't understand why sharing that memory should be so complex...
>
>As long as it's static, it's trivial. But as soon as you have to
>synchronise with potential changes of your process' mm, it starts to
>cause problems. Again, the concept of setting up the mapping during
>non-rt init of your driver and then using it in RT context is safe.
Right.
>> By reading the registers in the PCI board the driver can get the acquire
>> status (capturing, finished, etc).
>
>... and single this event by unblocking some potentially waiting user
>space, which was blocked in some related IOCTL of your driver.
Sorry, I didn't understand this phrase... My ioctl's never block...
>So, as Jeroen suggested as well, let the user register two or more exchange
>buffers, set up a shared memory region, and provide in IOCTL interface
>to inform the user about updates.
Do you mean by using polling or by a more efficient mechanism? I mean, how can
I use an IOCTL interface like a condition variable?
>> Well, let me explain what my problem is. I'm developing a framework for
>> developing rt applications for mobile robots. OROCOS seemed too complex
>> for
>
>Welcome to the club - we are working on the same topic at my institute.
:)
>> me... For testing the framework I built a simple robot with an optical
>> encoder on the weels. I developed an odometry system based on the encoder
>> sensors that worked well. I would like to write an application that does
>> position and speed control by using the images taken by the framegrabber
>> and compare the result with the odometry system for making a conceptual
>> proof of my framework for my master-thesis work.
>
>Sounds very interesting. Would be interesting to hear, when this works,
>what precision can be achieved with your hardware.
I'll let you know when I finish it -- if I finish! ;)
Best regards,
Rodrigo.
_______________________________________________________
Yahoo! doce lar. Faça do Yahoo! sua homepage.
http://br.yahoo.com/homepageset.html
