Php Serial Port Communication Linux Kernel

Once, the driver is probed, each of serial ports are exposed as a character device file by kernel to be used by userspace: /dev/ttySX X- Serial port number (zero indexed) Therefore UART0 -> /dev/ttyS0.

Hi, I would like to write a Linux kernel device driver that uses a serial port to talk to a speech codec chip with serial interface. I do not want to implement a device driver in userland since I consider it to be more clean and flexible to have the driver in kernel space.

So far I found out that there seem to be two possibilities to talk to a device over serial port from kernel space: One is to write a 'line discipline' driver similar to the SLIP or PPP drivers. The catch is that usually such drivers do not create a separate (i.e. Character-) device which I would like to have for my speech codec. Instead, in userland code the serial device (i.e. Autodesk sketchbook copic edition pronunciation. /dev/ttySn) needs to be opened and a special IOCTL needs to be issued, so that the default N_TTY terminal line discipline is changed to my own line discipline.

Among the source code for the SLIP and PPP drivers, I also found the article at useful (login can be found on ). The other possibility is to use the serio abstraction layer from the input layer which usually creates a separate character device on top of an existing serial device (i.e. While a speech codec is definitely not an input device, it seems to be an easy way for writing a serial speech codec driver. So far I did not find any documentation on how to use serio, although the code at linux/drivers/input/serio seems useful. I'm not sure if other suitable solutions exist as well, but if you know one, please tell me;) • What do you think is the best choice for my application? • So far I think using serio would be the better choice since it seems to be easy and small, right?

• Is using serio for a non-input device that bad? What would be the consequences? • What other options are there to write a kernel device driver that talks over a serial line?

Update: Another possibility seems to be to write a tty driver as described rather extensively in Oreilly's Linux Driver Development 3rd edition, chapter 18 book. So far I have not read through it, but it seems like a tty driver directly accesses a serial port. This is also visible on this site: Maybe writing a tty driver would be the proper way?

On the one side it is responsible for the creation of the character device and on the other side it is not tied to an improper layer (like it is the case with serio and the input layer). Cheers, knosses. Writing a tty driver is what you do if you want to implement a tty device -- a driver that creates a /dev/ttyXXX device that implements the normal serial-port functionality. Is that what you want? You haven't described what sort of a 'device' you want.

What is it's API going to be? Do you want a character device? An audio device for use by ALSA? A block device? [Since your problem is a general linux question and has nothing in particular to do with Atmel parts, this probably isn't the best place to be asking the question.]. Grante wrote:You haven't described what sort of a 'device' you want. What is it's API going to be?

Do you want a character device? An audio device for use by ALSA? A block device? I would like to create a character device. If one reads from the character device, the compressed speech samples (if there are any) should come out of the driver.

On the other side one should be able to write compressed speech samples to the character device. For speech codec configuration I would like to use ioctls (e.g. To set up the speech codec bit rate).

The other end of the speech codec is a PCM interface where uncompressed PCM speech samples will go in and out. These PCM samples will be transfered over a high speed SPI bus.

From a driver perspective this will be done in a separate ALSA driver which should not be part of the UART related discussion here. The ALSA driver is used to create a 'virtual' soundcard like interface with an audio source and sink. To get the picture one needs to consider both interfaces (SPI for PCM and UART for compressed speech data and control): If PCM speech samples are written to the speech codec by means of the ALSA driver, the chip will compress those speech samples. The compressed speech packets will then appear on the serial port where they can be read by the speech codec character device driver. Consecutively, a userland application will receive the compressed speech samples by reading from the mentioned character device. The other way works vice versa: A userland application writes compressed speech samples to the speech codec character device. The character device driver will transfer the compressed speech samples to the chip which in turn will decompress them.