UART and servo controller

UART and servo controller

[Carlo Caione]

Hi,
as an exercise I was trying to write a very simple module to drive a micro serial servo controller. This servo controller should be interfaced through a RS232-UART converter to a free UART port on the OMAP processor present on a beagleboard.
This servo controller is very simple: the serial commands are given through serial port following a strict protocol.
The idea was to create an ad-hoc  character driver and interact with it using ioctl() (or procfs) to give commands to the motors (which motor to move and the final position).
To learn about serial and UART drivers I was looking at the serial drivers for the omap (drivers/serial/omap-serial.c) but I suspect that this is not the right choice. 
The problem is that I don't want a serial device (/dev/ttyXX) the user can interact with (i.e. reading or writing to). The user should be able just to use ioctl() on an ad-hoc character device (i.e. /dev/motors) whereas the communication part through the UART and the communication protocol (configuration of the packet to send) should be up to the driver, in a transparent way.

Now my question is:
* How can I manage to hide the serial communication part into the driver (kernel), exposing to the user just an ad-hoc character device? It is enough for me a pointer to a driver similar to mine to take a look at the code. 

I suspect that I should use the UART driver because I need to set the communication parameters such as baudrate, parity and so on. But also when I use uart_register_driver() to register the driver I need (need?) e pointer to the console structure and this is not I want.

Thank you and sorry for the noob question.

--
Carlo Caione

UART and servo controller

[Greg KH]

On Tue, Mar 15, 2011 at 12:38:38AM +0100, Carlo Caione wrote:
> Hi,
> as an exercise I was trying to write a very simple module to drive a micro serial servo controller. This servo controller should be interfaced through a RS232-UART converter to a free UART port on the OMAP processor present on a beagleboard.
> This servo controller is very simple: the serial commands are given through serial port following a strict protocol.
> The idea was to create an ad-hoc  character driver and interact with it using ioctl() (or procfs) to give commands to the motors (which motor to move and the final position).
> To learn about serial and UART drivers I was looking at the serial drivers for the omap (drivers/serial/omap-serial.c) but I suspect that this is not the right choice. 
> The problem is that I don't want a serial device (/dev/ttyXX) the user can interact with (i.e. reading or writing to). The user should be able just to use ioctl() on an ad-hoc character device (i.e. /dev/motors) whereas the communication part through the UART and the communication protocol (configuration of the packet to send) should be up to the driver, in a transparent way.
> 
> Now my question is:
> * How can I manage to hide the serial communication part into the
> driver (kernel), exposing to the user just an ad-hoc character device?
> It is enough for me a pointer to a driver similar to mine to take a
> look at the code. 

It's a mess to do this, it would be easier, and simpler, to just do this
all from userspace, which is where the kernel is expecting this to come
from.

You can hook into an existing serial port, talking to the tty device,
but it is difficult and not anything I would recommend as a "simple"
kernel module, sorry.

good luck,

greg k-h

UART and servo controller

[Carlo Caione]

On 15/03/2011 00:50, Greg KH wrote:

> It's a mess to do this, it would be easier, and simpler, to just do this
> all from userspace, which is where the kernel is expecting this to come
> from.
>
> You can hook into an existing serial port, talking to the tty device,
> but it is difficult and not anything I would recommend as a "simple"
> kernel module, sorry.
>
> good luck,

Thank you for the reply. I thought it was simpler.
It is always hard to find out a kernel area simple enough to make 
experiments that are at the same time somehow useful.

--
Carlo Caione