>> 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