Re: [Xenomai-help] PCI Framegrabber real-time driver

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3306 bytes --]

Rodrigo Rosenfeld Rosas wrote:
>>> 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.
> 

Bah, once again:

"... and *signal* this event by unblocking some potentially waiting user
space *task*, which was blocked in a related IOCTL of your driver."

> Sorry, I didn't understand this phrase... My ioctl's never block...

In case you want synchronous frame access, you can create an IOCTL that
blocks until the hardware signals the arrival of a new one via an IRQ.
Of course, if you design an asynchronous interface, your IOCTL(s) may
only be used to switch the current buffer.

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

By using one of RTDM's services in your driver's IOCTL handler,
typically either a semaphore or an event. See the Xenomai API doc for
details - and have a look at the existing drivers...

> 
>>> 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! ;)

That's just a question of (re-)defining the goal when necessary. :)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]