On 12/12/2012 09:30 AM, Michael Haberler wrote:
>
> Am 12.12.2012 um 08:32 schrieb Gilles Chanteperdrix:
>
>> On 12/12/2012 07:54 AM, Michael Haberler wrote:
>>
>>> not strictly a Xenomai issue, but I'd completely bypass the
>>> kernel GPIO support and manipulate the GPIO registers directly -
>>> they are all memory mapped
>>>
>>> some inspiration here:
>>> http://git.mah.priv.at/gitweb/emc2-dev.git/blob/refs/heads/rtos-integration-preview1:/src/hal/drivers/hal_gpio.c
>>>
>>>
>>>
this runs from a userland thread but kernel shouldnt be much
>>> different
>>
>>
>> Yeah, good idea, depending on the way to access registers, you get
>> concurrence issues, conflicts between applications, a lot of fun.
>
> just to make sure I understand your suggestion:
>
> in kernel mode you'd suggest to go through gpiolib and use
> gpio_get_value/gpio_set_value if possible ?
>
> in user mode you can prepare things through sysfs but I dont see an
> alternative to memory-mapped register manipulation in that case if
> one wants to avoid system calls like read/write/open/ioctl which
> likely will be a dog on top of switching to secondary domain
This happens if you put the kernel/user split in the wrong place. For
instance, if your GPIOS are used to implement an I2C master,
implementing the I2C master in user-space manipulating GPIOS in
kernel-space is the wrong thing to do. What you should do is implement
the I2C master in kernel-space, and use it either in other drivers, or
in user-space. This way, you will get a write for a whole I2C transfer
instead of a write for each GPIO change. The same goes for a PWM, SPI
master, RS232 why not, etc... If your GPIOs are used to power on/power
off some devices, then using them in primary mode is probably not relevant.
>
> -m
>
>
>
>>
>> -- Gilles.
>
>
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
